Ops 4720/status change validation #4809
Conversation
josbell
requested review from
Santi-3rd,
fpigeonjr,
johndeange,
rajohnson90 and
weimiao67
as code owners
rajohnson90
left a comment
rajohnson90
left a comment
There was a problem hiding this comment.
What I've seen here all makes sense. Just respond to my one question and I'll be ready to approve.
| FEE="3.0", | ||
| START_DATE="2025-01-01", | ||
| END_DATE="2025-12-31", | ||
| END_DATE="2026-12-31", |
There was a problem hiding this comment.
If we had to update these because of the year, is there any chance we could push these out like 20 years and still keep the same test results? That way we don't have to do this yearly.
There was a problem hiding this comment.
I think the better fix would be to generate them dynamically but since @weimiao67 mentioned he had already done that in his PR that has not been merged yet I just left this hardcoded to pass e2e temporarily. I guess the only concern is if this PR gets merged after wei's
| enteredDescription: "Test description", | ||
| setEnteredDescription: mockFn, | ||
| needByDate: "12/31/2025", | ||
| needByDate: "12/31/2026", |
There was a problem hiding this comment.
Same question as test_load_procurementshops
| selectedCan: { id: 1, number: "G123456" }, | ||
| enteredAmount: 1000, | ||
| needByDate: "12/31/2025" | ||
| needByDate: "12/31/2026" |
There was a problem hiding this comment.
Same question as test_load_procurement_shops
| selectedCan: { id: 1, number: "G123456" }, | ||
| enteredAmount: 0, // This should fail validation | ||
| needByDate: '12/31/2025' | ||
| needByDate: "12/31/2026" |
There was a problem hiding this comment.
same question as test_load_procurement_shops
rajohnson90
left a comment
rajohnson90
left a comment
There was a problem hiding this comment.
Given that Wei has dynamic fixes for the things I'm concerned with, I am fine with approving this name.
What changed
When requesting a bli status change, now the validation of the agreement/blis will be postponed until user selects the blis that need to change. Furthermore, instead of validating all blis, only the selected blis will be validated.
Described what changes in this PR, at a high level
Previously the agreement/blis were validated using vest as a whole suite and done on page rendering. This change decouples the agreement and blis suites. They are not triggered not on page rendering but on bli selection.
Additionally there is also an unrelated fix to a warning emerging from Agreement table row where a div ended up being rendered as a direct child of a table when loading.
Issue
4720
Add link to issue here
#4720
How to test
Write out steps for how someone could test this PR against the acceptance criteria
Screenshots
If relevant, e.g. for a front-end feature
Definition of Done Checklist
Links
If relevant, e.g. for a link to a piece of markdown documentation