Reports stay individually GBR'd for former approver when they're restored as approver
If you havenβt already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: N/A Reproducible in staging?: Y Reproducible in production?: Y 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: @garrettmknight Slack conversation (hyperlinked to channel name): N/A
Action Performed:
- Create a workspace
- Invite 3 members Submitter + Approver A + Approver B
- Set Approver A as the approver for the whole workspace
- As Submitter, create and submit two separate expense reports with one expense each + submit the reports
- As Approver A, navigate to Submitter's expense chat
- As Admin, change the workspace approver to Approver B
- Verify that in Approver A's view, they're rerouted to Concierge and the two outstanding reports populate with GBR in their LHN.
- As Admin, change the workspace approver back to Approver A.
Expected Result:
- The individual GBR'd reports in LHN should disappear.
- Submitter's expense chat should reappear and GBR
Actual Result:
- Individaul GBR'd reports remain until they are viewed by the approver, at which point they're removed from LHN
- Submitter's expense chat only reappears and GBRs after accessing one of the individual GBR'd reports
Workaround:
The user can still access the reports to approve, it's just confusing.
Platforms:
Select the officially supported platforms where the issue was reproduced: ALL
Screenshots/Videos
Add any screenshot/video evidence
Triggered auto assignment to @greg-schroeder (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.
Taking over since I'm familiar with it. @Beamanator here's a vid:
https://github.com/user-attachments/assets/88e0d3bc-5feb-4ae7-873a-14a336e885dd
Love it - the setup steps & video make this super clear and straightforward, time to look for a backend contrib to help finish this off π
Posted: https://expensify.slack.com/archives/C086VHWPPUM/p1764763471487099
Root Cause
When policy chat reports are reshared with default approvers (e.g., after changing the default approver), hasParentAccess and hasOutstandingChildRequest weren't updated in Onyx until OpenReport was called. This caused incorrect "requires attention" states on the frontend.
Solution
Added logic in queueShareReportOnyxUpdates() to compute these fields when sharing:
- If the parent report is being shared in the current batch, set hasParentAccess = true directly
- compute the actual value of
hasOutstandingChildRequestusing hasOutstandingChildRequest()
DRAFT PR -> https://github.com/Expensify/Auth/pull/18544
@garrettmknight should we also consider this case for advanced approval policies?
Yeah, I think it originally came from that, but we can repro with simple approvals too.
Merged the fix for simple approvers, @ishpaul777 can you also make sure the advanced approvals case works here before we get a retest? The OP has test steps for advanced approval π
works well! π
Simple Approval
https://github.com/user-attachments/assets/65e501c3-ea4f-4485-9186-7cc51b01b313
Advanced (multi-step approval)
https://github.com/user-attachments/assets/a168669a-1da0-407f-9b09-a441f6e33f87
Ooh that is looking great!! We could close this out, OR should we make sure every conceivable flow change is working? Ex: category & tag approval changes
@garrettmknight, @Beamanator, @ishpaul777 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@garrettmknight when you have a moment could you check if GBR is working well when category / tag approvers are updated? I can't quite remember where we left that so we may need to revisit - or are we good to close this out?
FYI I'm OOO a few days next week
@garrettmknight @Beamanator @ishpaul777 this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
@garrettmknight can you please help with next steps here, Thanks!
Quick bump whenever you have time @garrettmknight π
@garrettmknight, @Beamanator, @ishpaul777 Eep! 4 days overdue now. Issues have feelings too...
not overdue
not overdue, still waiting for g-money to have time after holidays π
no updates still waiting