search

department-of-veterans-affairs / va-mobile-app

"If VA were a company, it would have a flagship mobile app."
https://department-of-veterans-affairs.github.io/va-mobile-app/
17 stars 2 forks source link

Investigate adding no associated facilities banner for appointments page #9640

Open aherzberg opened 1 month ago

aherzberg commented 1 month ago

BE has found that web has a FE check in their code to see if a user has any associated facilities before making an appointments calls. If they don't have any, they show a banner (See convo for screenshot of web banner: https://dsva.slack.com/archives/C023EFZPX4K/p1726589050979869). We are moving this check to the backend policy and are returning a unique error if no facilities are found. In an effort to make web and the app a more similar experience, we should also explore adding a banner.

At time of writing, the BE PR is not yet merged but will be shortly. Exact format of 403 facilities error will be in docs when it is. https://github.com/department-of-veterans-affairs/vets-api/pull/18486

StacyB2023 commented 1 month ago

Adding screenshot here: Screenshot 2024-09-17 at 11.43.14 AM.png

StacyB2023 commented 1 month ago

Adding to appts related epic. (Not related to logic updates)

mistymg commented 1 month ago

We can certainly implement the same-ish content web has in the alert. But first I'd like to know how old that alert is. Has CAIA had their eyes on it recently? Did they approve it? Would they make any changes to it? Then we can go from there on if the copy is good to go.

StacyB2023 commented 1 month ago

@aherzberg see above questions- FYI

jperk51 commented 3 weeks ago

@mistymg did something come of the sync mentioned in this thread? Either way I think I'd like to have a chat about exactly how we want to handle this. The banner in question is explicitly calling out scheduling and has some other references that make me suspicious about it's application for mobile along with our use of a preemptive authorized services check while web has that banner behind a check of the user info on page load. I just want to make sure we are all on the same page (BE, UX, Content) about how this should be handled before we call the BE work finished.

mistymg commented 3 weeks ago

@jperk51 Unfortunately, I haven't had time to chat with CAIA about this. And I'm over capacity on other priorities. If this needs to get on my radar, I'd suggest @StacyB2023 and @ala-yna work together to get a ticket made for me to eventually prioritize. If it's not in my backlog, I'm likely to miss it.

jperk51 commented 3 weeks ago

No worries. I think I was able to answer the questions anyways. When we return false for appts from authorized services we already call out what to do if you aren't registered at a facility. You can see screenshots of the "not authorized" scenario in #9903. Unless someone thinks otherwise we are going to add the facilities check to the appts authorized services so if a user doesn't have any facilities on record then we don't make unnecessary API calls and the user will see the screen in the ticket above.