7bc2b84d1d
All checks were successful
Build and Push Docker Image / build (push) Successful in 8m5s
The AWARD_MASTER role split sponsor jurors into a parallel UI that hid project files (only showed when the award was anchored to an evaluation round) and duplicated the jury voting path with no real difference in authority — tie-break and finalize were already governed by AwardJuror.isChair regardless of the user's global role. Inviting a juror via the award page defaulted to AWARD_MASTER, randomly fragmenting jury panels. This collapses the role into JURY_MEMBER + isChair: - specialAward.getMyAwardDetail now returns evaluation scores, chair visibility into other jurors' votes, and juror roster - specialAward.submitVote accepts an optional justification per vote - specialAward.confirmWinner moves from awardMasterProcedure to protectedProcedure (juror+chair check inside) - bulkInviteJurors creates JURY_MEMBER accounts and, when the award has a juryGroupId, also adds them to that JuryGroup so they appear on the round-page jury panel - jury award page renders justification, eval-score badges, and a chair tools panel with vote tally + finalize-winner CTA - juryGroup.list includes attached SpecialAwards; the jury-list UI shows a trophy pill alongside round pills - (award-master) route group, awardMasterProcedure, AWARD_MASTER role enum value, and AWARD_MASTER_DECISION decisionMode are deleted - migration demotes any residual AWARD_MASTER users to JURY_MEMBER and recreates the UserRole enum without the value Coup de Coeur on prod: Didier (the sponsor juror added today as AWARD_MASTER by the buggy invite form) was migrated to JURY_MEMBER and attached to the existing "Coup de Coeur" JuryGroup; the SpecialAward itself was linked to that group (juryGroupId was NULL). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
30 lines
989 B
SQL
30 lines
989 B
SQL
-- Drops AWARD_MASTER from the UserRole enum.
|
|
--
|
|
-- Any row still holding AWARD_MASTER is demoted to JURY_MEMBER (singular role)
|
|
-- or filtered out of the roles[] array (multi-role) before the enum swap, so
|
|
-- the type alteration is safe even if the prod migration was missed.
|
|
|
|
UPDATE "User" SET role = 'JURY_MEMBER' WHERE role = 'AWARD_MASTER';
|
|
UPDATE "User" SET roles = array_remove(roles, 'AWARD_MASTER') WHERE 'AWARD_MASTER' = ANY(roles);
|
|
|
|
CREATE TYPE "UserRole_new" AS ENUM (
|
|
'SUPER_ADMIN',
|
|
'PROGRAM_ADMIN',
|
|
'JURY_MEMBER',
|
|
'MENTOR',
|
|
'OBSERVER',
|
|
'APPLICANT',
|
|
'AUDIENCE'
|
|
);
|
|
|
|
ALTER TABLE "User" ALTER COLUMN role DROP DEFAULT;
|
|
ALTER TABLE "User"
|
|
ALTER COLUMN role TYPE "UserRole_new" USING role::text::"UserRole_new";
|
|
ALTER TABLE "User" ALTER COLUMN role SET DEFAULT 'APPLICANT';
|
|
|
|
ALTER TABLE "User"
|
|
ALTER COLUMN roles TYPE "UserRole_new"[] USING roles::text[]::"UserRole_new"[];
|
|
|
|
DROP TYPE "UserRole";
|
|
ALTER TYPE "UserRole_new" RENAME TO "UserRole";
|