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/
10 stars 2 forks source link

BUG - 3 - All -Benefit summary and service verification letter stuck showing loading component when beneficiary data request fails #6951

Open theodur opened 9 months ago

theodur commented 9 months ago

What happened?

When the request for fetching beneficiary data fails, the Benefit summary and service verification letter screen is stuck showing the loading component. This is caused by the logic in the onViewLetter function that gets called when a user tries to view the letter.

It's not clear whether we should show an error if the beneficiary data request fails, as the logic for generating the letter will still generate the letter if beneficiary data isn't available. It needs to be determined whether we should show an error when the request fails, or if we should still allow the user to view the letter without the beneficiary data included.

Specs:

Steps to Reproduce

Desired behavior

The Benefit summary and service verification letter should not be stuck on the loading component if the beneficiary data request fails.

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See [Bug Tracking](https://department-of-veterans-affairs.github.io/va-mobile-app/docs/QA#issue-severity) for details on severity levels

Linked to Story

Screen shot(s) and additional information

Full JSON response for services related to issue (expand/collapse)

Ticket Checklist

TKDickson commented 9 months ago

Hey @bischoffa - we're going to need UX decision on this part (below). I've seen a few bugs where there's been a splitting off UX ticket for that decision-making just recently, is there a formal process for that (who should spin up the UX ticket, where the bug ticket goes in teh meantime, ticket templates) that you know of? Should I ask a UX person instead?

TKDickson commented 9 months ago

Whoops. Decision needed on this part:

It's not clear whether we should show an error if the beneficiary data request fails, as the logic for generating the letter will still generate the letter if beneficiary data isn't available. It needs to be determined whether we should show an error when the request fails, or if we should still allow the user to view the letter without the beneficiary data included.

bischoffa commented 9 months ago

@TKDickson Thanks! Yep if there is a UX (other another discipline) descision needed I am breaking off a separate ticket.  PM owning bugs (right now me) is splitting out the UX ticket and coordinating with Jen to prioritize. 

As for the process, QA can scrub tickets as needed. Thoughts on if we modify the process so that if QA identifies UX decision is needed to then add the label blocked-ux? PMs can take care of anything after that.

TKDickson commented 9 months ago

@bischoffa sounds good! Will add the blocked-UX label and move to the blocked column (after the other scrub stuff is done) when we see them. That separate UX decision ticket is a good idea.

timwright12 commented 7 months ago

@bischoffa @TKDickson any news on this one? Been blocked by UX for a while

bischoffa commented 7 months ago

@timwright12 not yet. UX has had other priorities as of now that fit into their bug work and tech debt.

Sparowhawk commented 4 months ago

@wavelaurenrussell if you could respond in this ticket instead of the other one that would be great lol