Open kpethtel opened 3 months ago
@jperk51 requested that i summarize my concerns about this ticket here. In summary, I think we need to consider the pros and cons of using enrollment status as part of our access policy.
Fetching enrollment status on every authorized services request will add an additional dependency to the endpoint as well as some additional latency. This is acceptable if it's necessary, but it's also not ideal because the large majority of users are likely enrolled and will continue to be enrolled. So to check on their enrollment status every session will result in a large number of unnecessary requests, which will put additional strain on the vets-api and upstream servers.
It may be better to determine how often we need to re-check enrollment for enrolled veterans as well as caching strategies. If we decide that long-term caching is needed, we can create a DB record in the vets-api. If we want to re-check occasionally, we could cache in the frontend.
Having a meeting tomorrow with FE and QA to decide what option we want to go through with
Backend is going to proceed with a larger effort to improve all authorization policies in vets-api that we use. @StacyB2023 let's get together to make an epic for this
Hey @jperk51 @StacyB2023 - what's the blocker on this ticket? Or is it unblocked? cc @dumathane
Setting as blocked as I have been unable to get a response from any upstream teams on if using enrollment status is a correct metric to block appeals access. @DonMcCaugheyUSDS let me know when you have some time jump into these convos.
As described here, the appeals policy does not provide a good user experience. Investigate which policy we should use and change accordingly. This ticket may also provide insight into which policy we should use.
ACs: