-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Include VendorApprovalStatus
table
#1328
base: development
Are you sure you want to change the base?
Conversation
…ons.tests[].viewers[] and TestPlanReport.vendorReviewStatus
…endorApprovalStatus
#1329 should fix the build error happening here. |
# Conflicts: # client/tests/e2e/snapshots/saved/_data-management.html # client/tests/e2e/snapshots/saved/_test-queue.html
VendorApprovalStatus
tableVendorApprovalStatus
table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great improvement! I am especially happy about the removal of viewers
. I didn't realize that this value wasn't being used to track viewed tests in normal runs as well.
I looked through the code and tested everything manually. Everything works great for the most part. I am a bit on the fence about the loss of information about reviewed tests for admins. It doesn't feel like a major problem but in the current version of the app when an admin views candidate reports they can see tests they have already looked at in the test nav. This doesn't seem too important but it does make me wander if we want that test nav to always show tests that have been viewed by the vendor reviewer since that is the most important info.
Other than that, just a few small comments inline. I'll pass back to you to address any that you think are appropriate
@@ -295,12 +285,13 @@ const updatePhaseResolver = async ( | |||
recommendedPhaseTargetDate: recommendedPhaseTargetDateValue, | |||
deprecatedAt: null | |||
}; | |||
} else if (phase === 'RECOMMENDED') | |||
} else if (phase === 'RECOMMENDED') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wild that these were missing.
vendorId: user.vendorId || user.company?.id, | ||
values: { | ||
reviewStatus, | ||
approvedAt: reviewStatus === 'APPROVED' ? new Date() : null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: does modification of this value need to be exposed outside of the service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at all! Could be a useful way to quickly shift the status in a development sense but certainly not something that should remain. Good catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 7cd4f8b
testPlanReportId, | ||
userId, | ||
vendorId | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be that status sometimes applies to a plural or it might be that Ids
is plural in the function name but it took a second for me to understand that this is the get single function and the below is the get all function. Maybe do a quick check to make sure all ids were passed in to prevent that confusion in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was more following the existing pattern and this seemed slightly different given a composite is used here! I've chosen to just drop the s
in 317aa5c. Let me know if this works
) | ||
.map(({ id }) => id); | ||
const isApproved = testPlanReport.vendorReviewStatus === 'APPROVED'; | ||
const date = new Date(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this matter? It seems that there was no tracking of the approval date previously so I guess it is fine to use the current date but curious your thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not. And it being falsified as a one-off could be explained. The trade off is if approvedAt gets surfaced in the future, some reviews won't have dates available. If we're okay with that, I could leave a note in so that detail is remembered.
{ transaction } | ||
); | ||
|
||
await queryInterface.createTable( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the frozen table definition
}); | ||
} | ||
} catch (error) { | ||
// console.error('addViewerResolver.error', error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to leave this in? I wouldn't mind leaving uncommented error logging in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure can uncomment.
P.S. I think this is part of a wider need I've been coming across, especially when debugging in a deployed environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…yIds -> getVendorApprovalStatusById
…failling summary; Update snapshots
Going through the current viewers, I realized a small amount are actually viewed by admins, which made me feel more comfortable doing away with that. But this is a question we can raise with them to see if this information is worth preserving for their needs before moving forward. |
I agree that the tiny amount of "data loss" is inconsequential here. I meant more for moving forward, it feels slightly odd to have the UI show "viewed" in the test nav temporarily and then when you navigate away and back, have it reset. I almost want it to persist info about vendor viewed tests for everyone. It really isn't a strong opinion though and I'd be happy to merge as-is and consider whether something like this makes sense in the future. |
Okay, I understand your point on that better now! Let me take a look into that. |
# Conflicts: # client/tests/e2e/snapshots/saved/_account_settings.html # client/tests/e2e/snapshots/saved/_data-management.html # server/resolvers/helpers/processCopiedReports.js
Address #1310