MISUV-8224-optin-with-previously-submitted-updates #2479
Conversation
…x-view-change-frontend into MISUV-8136-choose-year-srvc
…x-view-change-frontend into MISUV-8136-choose-year-srvc
…x-view-change-frontend into MISUV-8136-choose-year-srvc
…d into MISUV-8223-optin-check-your-answer
|
|
There are 83 commits on this branch ranging back to 7th Aug. I'm guessing it's because we're stacking work from previous tickets. Is it possible to get some of the older tickets closed off to make reviewing this easier? I'm happy for spin-off tickets to be made to catch loose-ends like Welsh translations that are missing. |
Sure @ian-hmrc , but there are no stacked tickets etc at the moment, let's get this PR reviewed and we can look at other tickets next |
OK, I can see you've merged main, and that's taken the number of files to review from 33 to 11. I'll have a look at that. |
| proposition <- OptionT.liftF(fetchOptInProposition()) | ||
| quarterlyUpdatesCountForOfferedYears <- OptionT.liftF(getQuarterlyUpdatesCountForOfferedYears(proposition)) | ||
| showPreviouslySubmittedUpdatesWarning = quarterlyUpdatesCountForOfferedYears.counts | ||
| .filter(v => v.taxYear == intentTaxYear).map(_.count).headOption.getOrElse(ZeroCount) > ZeroCount |
There was a problem hiding this comment.
I'm questioning if this is the right way to calculate this for Opt In? If the user is Opting In, then they should currently be reporting Annually, so shouldn't have any quarterly updates, so won't the count of quarterly updates always be zero? This might be a more subtle difference between Obligations (Updates) and Submissions. I've asked Design, but let's pick up tomorrow and see if we can make sure we've understood this correctly.
optin-with-previously-submitted-updates