4245 change request process and factory#4331
Conversation
| organizationId, | ||
| this.faker.helpers.arrayElement(submitterPool).userId, | ||
| this.faker.helpers.arrayElement(reviewerPool).userId, | ||
| budgetReasonId() |
There was a problem hiding this comment.
I'd name this better. something like generateBudgetReasonId.
wavehassman
left a comment
wavehassman
left a comment
There was a problem hiding this comment.
A couple of general things:
- You can't have multiple simultaneous pending CRs on the same WBS element/category/account code/etc
- When a change request is accepted, it should apply their changes, so if a cr status is marked accepted, make sure the wbs reflects that
- Budget CRs are really only made on account codes for the finance team
wavehassman
left a comment
wavehassman
left a comment
There was a problem hiding this comment.
Two things I forgot to mention:
- Leadership, stage gate and activation crs are automatically accepted and implemented, so there status should always be approved
- Activation moves the work package's start and stage gate moves its duration
| const outcomesForOrderedCrs = (faker: Faker, count: number): ReviewOutcome[] => | ||
| Array.from({ length: count }, (_, index) => (index === count - 1 ? latestOutcome(faker) : resolvedOutcome(faker))); | ||
|
|
||
| const orderedSubmissionDates = (faker: Faker, timeline: DateRange, count: number): Date[] => |
There was a problem hiding this comment.
Dates here are bounded only by timeline, never capped at now
Since project/work-package timelines can extend into the future, this can produce a CR dateSubmitted/dateReviewed that's ahead of now
…rtheastern-Electric-Racing/FinishLine into 4245-generate-change-requests
|
|
||
| const wbsChangeRequestInputs: Prisma.Change_RequestCreateInput[] = []; | ||
|
|
||
| for (const { project, timeline } of projects) { |
There was a problem hiding this comment.
No filter for future-dated projects/work packages and combined with cappedWindow, this collapses their CRs to dateSubmitted = now, before the WBS element's own start
Should prob skip not yet started ones here, like ReimbursementRequestProcess does
wavehassman
left a comment
wavehassman
left a comment
There was a problem hiding this comment.
This isn't your doing, but it creates a bug with the merge:
Line: src/backend/src/prisma/factories/description-bullet.factory.ts:52
Never sets dateTimeChecked/userCheckedId, so every bullet is permanently unchecked. Since reviewStageGateChangeRequest throws if a work package has any unchecked bullet, and every work package now gets at least one, this makes every accepted STAGE_GATE CR an unreachable state. Some bullets need to get checked before a work package's STAGE_GATE CR is generated/accepted
| } | ||
| }; | ||
|
|
||
| const changesCreateInput = ( |
There was a problem hiding this comment.
never sets dateImplemented
| case CR_Type.LEADERSHIP: | ||
| return { | ||
| leadershipChangeRequest: { | ||
| create: { |
There was a problem hiding this comment.
aren't they just changing them to the same ones? same for activation
3 participants
Changes
Added generation process for change requests. 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 #4245