Conversation
What was broken The My Assignments endpoint only returned engagements where the authenticated member had a selected or assigned record, so completed and terminated engagement details disappeared from the member view. Root cause findMyAssignments reused the active assignment status list for both the engagement filter and included assignment records. What was changed Added a My Assignments status set that includes SELECTED, ASSIGNED, COMPLETED, and TERMINATED. The endpoint now uses that set for member assignment filtering, and the API documentation describes active and past assignments. Any added/updated tests Added an EngagementsService test covering active and past assignment records in the My Assignments query.
PM-4925: Include past assignments in My Assignments API
What was broken Private engagement updates could still reject reassigning the same member when the request included both a historical completed or terminated assignment row and the new assignment row. The update flow also treated a single same-member row as matching historical assignment data in the prior fix, which could avoid creating the new active assignment. Root cause The assignment update logic compared duplicate private assignment payload rows directly against the required member count and matched incoming rows to assignments without separating active slots from terminal history. That left terminal history rows competing with new active assignment rows for uniqueness and mutation planning. What was changed Added assignment mutation planning for private engagement updates that groups rows by member, preserves terminal assignment history, updates existing active rows, creates one new active row when reassignment is valid, and terminates omitted active rows by assignment id. Allowed duplicate member rows only inside the private assignment update planner so duplicate active assignments are still rejected. Aligned stale e2e expectations with the current application route and active-assignment filtering so the full test command runs cleanly. Any added/updated tests Added engagement service coverage for duplicate payload rows with a completed historical assignment. Added coverage for creating a new assignment when the previous same-member assignment is completed or terminated and only the new row is submitted. Updated e2e expectations for current route and active-assignment query behavior.
PM-4892: allow private reassignment after terminal assignments
What was broken QA still saw a Prisma unique-conflict error when reassigning the same member to a private engagement after the earlier assignment was completed. The prior service planner fix was correct for terminal assignments, but a QA branch or environment can still retain the old broad engagement/member unique index and reject the new history row. Root cause The database uniqueness shape must allow multiple historical rows for the same engagement and member while still enforcing one active assignment. When the stale broad unique index remains, creating the new selected assignment after a completed or terminated assignment fails before the service can return the expected updated engagement. What was changed Added a follow-up migration that defensively drops the old broad EngagementAssignment engagementId/memberId unique index. The migration also re-creates the non-unique lookup index and the active-only unique index for SELECTED and ASSIGNED assignments. Any added/updated tests No new tests were added because the existing engagement service coverage already exercises same-member reassignment after COMPLETED and TERMINATED assignments. Validation was run with lint, build, and the full Jest suite.
PM-4892: reinforce assignment history uniqueness migration
What was broken QA still saw the Prisma unique-conflict error when assigning a private engagement to a member whose previous assignment on the same engagement had been completed. Root cause The service planner and previous named-index migration covered the expected code path, but QA databases can still retain a broad engagement/member assignment unique constraint or index under a different generated name. That stale uniqueness rejects the valid new assignment history row before the service can return the updated engagement. What was changed Added a follow-up migration that discovers and drops any unique constraint or unique index on the exact EngagementAssignment engagementId/memberId pair, regardless of name. The migration then restores the non-unique engagement/member lookup index and recreates the intended active-only unique index for SELECTED and ASSIGNED assignments. Any added/updated tests No new tests were added because existing engagement service coverage already exercises same-member reassignment after COMPLETED and TERMINATED assignments. Validation was run with lint, build, and the full Jest suite.
PM-4892: drop stale assignment uniqueness constraints
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://topcoder.atlassian.net/browse/PM-4892