As a COR, I need to edit the procurement shop on an agreement with with no BLs in a status higher than Planned, and know that it requires an approval, so that I understand how my edit will impact the overall budget
Preconditions
A contract exists with at least one budget line in Planned status but no budget lines in any status higher than that.
Acceptance Criteria
[ ] On a given existing contract, authorized users are able to select a different procurement shop from the one currently selected and the changes are successfully persisted. Authorized users would be limited to Project officer, named team members, team leader associated with any CANs associated with the BLs of the agreement, Division Director linked to associated CANs, budget team, and System Admin(s).
[ ] Changing the procurement shop should not be allowed if the contract has any BLs in Executing or higher status unless the user is a System Admin
[ ] Any BLs on the agreement in Planned status should change to In Review and start an approval process to get approved due to this financial change.
[ ] In this scenario where the agreement has Planned BLs, the procurement shop cannot be altered again until the active request to alter the procurement shop has been reviewed by an approver.
[ ] The user should be aware that making the procurement shop change will require re-approval of any Planned BLs
[ ] Validation rules would still need to be enforced on contract metadata such that required attributes based on the associated BL status can't be emptied out or otherwise made invalid
[ ] Upon successful committal of the pending procurement shop change, if a given contract has one or more BLs in Planned status such that changing the Procurement shop requires approval, the stored fee amount should not change at this time
[ ] A contract with only draft BLs should have all the fees updated based on the procurement shop change.
[ ] Upon successful committal of the pending procurement shop change, relevant entries should be recorded in the event/history table(s) of who made what changes when and this event should be properly rendered in the history of changes to the agreement.
Test
[ ] Upon submitting the new procurement shop for approval, the agreement should still have the original procurement shop in place/rendered until it's approved.
[ ] The user can't submit Yet Another procurement shop change while a current/previous change in the procurement shop is awaiting review.
[ ] If all BLs are in draft state, no approval would be required anyway for the BLs or contract metadata change.
[ ] If at least one BL is in planned state, approval for the proc shop change would be required.
[ ] Even if approval is required, original fees shown pre-change would still persist until approved.
Tasks
UX
designs are already done as part of #1964
Dev
essentially encompassing what #1473 was intended to do.
Definition of Done Checklist
[ ] UI works as designed (UX team)
[ ] PR(s) have been merged to main
[ ] Design/tech debt eliminated
[ ] New design/tech debt documented (if applicable)
[ ] Build process updated
[ ] Documentation updated or added
[ ] Feature flags/toggles created
Additional Context & Resources
Weigh the rules and AC here against #1473 and #2139 and make any refinements needed based on prevailing logic and business needs at the time this is getting worked
A more-narrative document outlining potential scenarios and needs being addressed is here
User Story
As a COR, I need to edit the procurement shop on an agreement with with no BLs in a status higher than Planned, and know that it requires an approval, so that I understand how my edit will impact the overall budget
Preconditions
Planned
status but no budget lines in any status higher than that.Acceptance Criteria
Executing
or higher status unless the user is a System AdminPlanned
status should change to In Review and start an approval process to get approved due to this financial change.Planned
BLsPlanned
status such that changing the Procurement shop requires approval, the stored fee amount should not change at this timeTest
Tasks
UX
Dev
Definition of Done Checklist
Additional Context & Resources