You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[HIGH][$250] Send invoice - Category is missing in confirmation page but it is present in invoice view #41281
Version Number: 1.4.68-0 Reproducible in staging?: Yes Reproducible in production?: No (New feature) If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs:https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: Applause Internal Team Slack conversation:
Action Performed:
Pre condition:Create a new workspace and use to send Invoice
Go to staging.new.expensify.com
Go to FAB > Send invoice.
Enter amount and select a participant.
Note that "Category" is not present in the confirmation page.
Create the invoice.
Click on the preview in workspace chat.
Expected Result:
"Category" row should be present in the confirmation page if it is present in the invoice details page.
Actual Result:
"Category" row is not present in the confirmation page when it is present in the invoice details page.
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
Identify the pull request that introduced this issue and revert it.
@sonialiap FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.
@youssef-lr could you help assess whether there was a regression here? Christi is on parental leave and I'm getting lost in the code.
This issue here was solved with PR 41723, then your PR 41945 changed the solution, this caused the issue to resurface and the GH issue was reopened. A new PR, 47474 was pushed and needs payment. The resurfaced issue was not flagged as a regression. Comment from the C+. Do you think there was a regression caused by #41723 ?
This is ready for payment, we just need to figure out whether there was a regression. @youssef-lr bumping my question from above in hopes that you can help #41281 (comment)
@Pujan92@gijoe0295 because this latest PR was a fix for a regression on this issue, it does not qualify for additional payment. Had this been caught within the regression period then the payment would have been decreased but since it popped up a month later, you received full payment for the first fix and nothing needs to happen at this point. Thank you for quickly addressing the regression!
Activity
melvin-bot commentedon Apr 30, 2024
Triggered auto assignment to @robertjchen (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.melvin-bot commentedon Apr 30, 2024
Triggered auto assignment to @sonialiap (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.github-actions commentedon Apr 30, 2024
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
m-natarajan commentedon Apr 30, 2024
We think this bug might be related to #wave-collect - Release 1
m-natarajan commentedon Apr 30, 2024
@sonialiap FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.
robertjchen commentedon Apr 30, 2024
Does not appear to be a serious deploy blocker to me and can be addressable by external contributors 👍
166 remaining items
sonialiap commentedon Sep 16, 2024
Apologies, I must have accidentally closed the tab and lost the issue. Thanks for the ping
sonialiap commentedon Sep 16, 2024
@youssef-lr could you help assess whether there was a regression here? Christi is on parental leave and I'm getting lost in the code.
This issue here was solved with PR 41723, then your PR 41945 changed the solution, this caused the issue to resurface and the GH issue was reopened. A new PR, 47474 was pushed and needs payment. The resurfaced issue was not flagged as a regression. Comment from the C+. Do you think there was a regression caused by #41723 ?
sonialiap commentedon Sep 20, 2024
This is ready for payment, we just need to figure out whether there was a regression. @youssef-lr bumping my question from above in hopes that you can help #41281 (comment)
melvin-bot commentedon Sep 23, 2024
@youssef-lr, @Pujan92, @sonialiap, @cristipaval, @gijoe0295 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
youssef-lr commentedon Sep 24, 2024
It looks like it was a regression indeed @sonialiap
sonialiap commentedon Sep 24, 2024
Thanks for checking, Youssef!
@Pujan92 @gijoe0295 because this latest PR was a fix for a regression on this issue, it does not qualify for additional payment. Had this been caught within the regression period then the payment would have been decreased but since it popped up a month later, you received full payment for the first fix and nothing needs to happen at this point. Thank you for quickly addressing the regression!