Descoping CR Feature#4206
Conversation
…ma-changes #4168 schema changes
…oval-logic #4170 Update Approval Logic
…slack-notif-diff-on-cr-submit
#4173 simplified making a CR
…k-notif-diff-on-cr-submit #4171 Slack Notification with Diff
…e-gate-input #4176 added dateCompleted to stage gate
…n making a new project
…ve-old-cr-stuff #4174 frontend changes
…lack-button #4172 started cr approve slack button
There was a problem hiding this comment.
Functionality notes:
- When I change the lead and then change another part of a project (such as the name or description or budget), it gives this error:
(this does not appear to be an issue on work packages) - Changing only the budget on a project makes a standard change request not a budget change request (I believe this was already a bug). This also feeds into functionality that I don't think we don't have right now: we should make multiple change requests if different kinds are required. For example, if I change the leadership, budget, and description, there should be a leadership CR, a standard CR, and a budget CR. On a completely seperate not I don't think we shoul dactually need CRs for changing project information other than budget, but thats another thing. If we want to say this bullet is out of scope for this branch thats fine but should definately go in the fall CR epic
- When I have the modal to submit a CR and click the dropdown to select a reviewer it is cut off by the modal and I have to scroll

- After I submit a CR it takes me back to the CR page. it should take me to the change requests page
- implement and create change request buttons are not merged into one but they should be
- Allow any head or admin plus requested reviewer to review on slack
|
|
||
| try { | ||
| // Action-specific validation: verify action_id | ||
| if (firstAction.action_id !== 'approve_cr') { |
There was a problem hiding this comment.
I'm pretty sure this is unreachable code? If its not Im confused when this would happen and we should have a more specific error message / guard. If anything we should not be calling the controller if this was the case
|
|
||
| // Action-specific validation: verify value format | ||
| let actionValue: CrApprovalActionValue; | ||
| try { |
There was a problem hiding this comment.
really not a fan of nested try catches
| Prisma.validator<Prisma.Project_Proposed_ChangesDefaultArgs>()({ | ||
| include: { | ||
| teams: getTeamQueryArgs(organizationId), | ||
| car: { include: { wbsElement: true } }, |
| Prisma.validator<Prisma.Work_Package_Proposed_ChangesDefaultArgs>()({ | ||
| include: { | ||
| wbsProposedChanges: { | ||
| include: { |
| include: { | ||
| wbsProposedChanges: { | ||
| include: { | ||
| links: { where: { dateDeleted: null }, include: { linkType: true } }, |
| SET | ||
| why = CONCAT( | ||
| 'Type: ', cr.type::text, | ||
| CASE WHEN sc.what IS NOT NULL THEN CONCAT(' | What: ', sc.what) ELSE '' END, |
There was a problem hiding this comment.
can we use newlines instead of pipes? the pipes are kind of hard to interpret retrospectively
|
|
||
| const addDiff = (label: string, before: string | number | null | undefined, after: string | number | null | undefined) => { | ||
| const b = String(before ?? '(none)'); | ||
| const a = String(after ?? '(none)'); |
There was a problem hiding this comment.
nit: if before or after could be a number, they could be 0, so lets guard against that getting changed to '(none)'
| ): string => { | ||
| if (!proposed) return ''; | ||
|
|
||
| const isWpChange = 'startDate' in proposed; |
There was a problem hiding this comment.
This is a very fragile way to determine which type we are working with. In this case an isntanceof actually makes a lot more sense. In addittion, you can actuall get kind of fance with the types and do something like:
const isWpChange(cr: ProjectProposedChangesCreateArgs | WorkPackageProposedChangesCreateArgs | undefined): cr is WorkPackageProposedChangesCreateArgs {
return cr instanceof WorkPackageProposedChangesCreateArgs
}
and vise versa with the project. The cr is <type> means that if the predicate passes in an if guard (like below), you the type checker will automatically narrow into that specific type and you don't need to cast
|
|
||
| await Promise.all(changePromises); | ||
| if (isWpChange) { | ||
| const wpProposed = proposed as WorkPackageProposedChangesCreateArgs; |
There was a problem hiding this comment.
wouldn't be needed if you use the above syntax
| addNew('Manager', wpProposed.managerId); | ||
| addNew('Start date', wpProposed.startDate); | ||
| addNew('Duration', wpProposed.duration); | ||
| addNew('Stage', wpProposed.stage); |
There was a problem hiding this comment.
I feel like we should be able to collablse the addNew and addDiff into a single function that just knows an empty value means you are adding a new, but if I'm missing something this is fine to leave as is
Changes
Removes all legacy CR UI elements and updates the CR detail page as part of the broader CR descoping epic. Specifically:
Checklist
It can be helpful to check the
ChecksandFiles changedtabs.Please review the contributor guide and reach out to your Tech Lead if anything is unclear.
Please request reviewers and ping on slack only after you've gone through this whole checklist.
yarn.lockchanges (unless dependencies have changed)Closes #4157