Skip to content

[$250] Expense report-Submit & approve button not disappear until page refreshed #48463

Closed

Description

@izarutskaya

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!


Version Number: 9.0.28.0
Reproducible in staging?: Y
Reproducible in production?: N
Found when validation PR: #48362
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

Precondition: log into OD as an admin, create a control policy, enable workspace chats, select "Advanced Approvals", invite 3 members (non-admin): 2 approvers and 1 submitter, set the approval flow as submitter submits to approver 1

  1. Log into ND as submitter
  2. Navigate to the workspace chat
  3. Submit one manual expense
  4. Open the report and click on the "Submit" button
  5. As admin, change the the submitter's submitsTo to approver 2 in OD
  6. Log into ND as approver 1
  7. Opened the submitted report
  8. Click on the "Approve" button

Expected Result:

The 'Submit" button disappears immediately for the submitter (step 4) and the "Approve" button disappears for the approver (step 8)

Actual Result:

The "Submit" and "Approve" button do not disappear until the page is refreshed or it is clicked on the second time (the "Approve" button)

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop

Screenshots/Videos

Bug6591339_1725333837619.Recording__737.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~01efec68070b933fc3
  • Upwork Job ID: 1831071506567798044
  • Last Price Increase: 2024-10-29
  • Automatic offers:
    • nkdengineer | Contributor | 104649054
Issue OwnerCurrent Issue Owner:

Activity

  1. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Sep 3, 2024
  2. melvin-bot commented on Sep 3, 2024

    @melvin-bot

    Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

  3. melvin-bot commented on Sep 3, 2024

    @melvin-bot

    Triggered auto assignment to @slafortune (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.

  4. github-actions commented on Sep 3, 2024

    @github-actions
    Contributor

    👋 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:

    1. Identify the pull request that introduced this issue and revert it.
    2. Find someone who can quickly fix the issue.
    3. Fix the issue yourself.
  5. izarutskaya commented on Sep 3, 2024

    @izarutskaya
    Author

    We think this issue might be related to the #wave-control

  6. izarutskaya commented on Sep 3, 2024

    @izarutskaya
    Author

    Production

    Recording.739.mp4
    Recording.2788.mp4
  7. srikarparsi commented on Sep 3, 2024

    @srikarparsi
    Contributor

    Looked into this and I think this might be a problem with manually submitting reports. I verified this by:

    1. Creating a workspace
    2. Setting the submit frequency to manual
    3. Creating an expense
    4. Submitting the expense
    5. Seeing the submit button re-appear

    (First part of the video is from staging and the second is from production)

    manualSubmitBug.mov
  8. srikarparsi commented on Sep 3, 2024

    @srikarparsi
    Contributor

    I don't think this is a backend bug because the SubmitReport response is the same on staging and production.

  9. 134 remaining items

  10. Beamanator commented on Nov 29, 2024

    @Beamanator
    Contributor

    Do you mean the report when approver1 clicks Approve is then sent to the "new" approver to approve as well? If so, I'm not aware of that historical logic. I would have assumed this report would go to the approvesTo || overLimitForwardsTo set for approver1.

    I know I USED TO think that way 😅 then I did a decent amount of testing and found that not to be the case, I thinkkkkk I explained in slack somewhere... it's all related to this "conclusion" i posted

  11. Beamanator commented on Nov 29, 2024

    @Beamanator
    Contributor

    So the point is: If a report already has a manager & they get removed from the approval chain, we stop caring about the current manager's approval chain, and we purely care about "who is next to approve in the submitter's current / new approval chain"

  12. Beamanator commented on Nov 29, 2024

    @Beamanator
    Contributor

    In ReportUtils::buildApprovalChain (this is the OldDot approval-chain building... NewDot does it all in Auth) you can see that the current report manager is never inserted into the chain, we ONLY insert:

    1. $ruleApprovers (category / tag approvers)
    2. The approvalChain built from the policy's submitsTo -> forwardsTo -> ...
  13. melvin-bot commented on Dec 2, 2024

    @melvin-bot

    @slafortune, @NikkiWines, @eh2077, @nkdengineer Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

  14. eh2077 commented on Dec 2, 2024

    @eh2077
    Contributor

    Not overdue, discussion is ongoing

  15. trjExpensify commented on Dec 2, 2024

    @trjExpensify
    Contributor

    In ReportUtils::buildApprovalChain (this is the OldDot approval-chain building... NewDot does it all in Auth) you can see that the current report manager is never inserted into the chain, we ONLY insert:

    1. $ruleApprovers (category / tag approvers)
    2. The approvalChain built from the policy's submitsTo -> forwardsTo -> ...

    Great stuff! So I agree we can close this issue then. :)

  16. slafortune commented on Dec 3, 2024

    @slafortune
    Contributor

    Thanks all! Those details are super helpful

  17. moved this from Bugs and Follow Up Issues to Done in #expensify-bugson Dec 3, 2024
  18. nkdengineer commented on Dec 16, 2024

    @nkdengineer
    Contributor

    @slafortune I believe compensation is due for this issue since it was assigned and I spent a lot of effort following this issue and worked on the PR here before we decided to close this as expected.

    This is a similar case, seems the rule based on that thread is full compensation in such case.

    @Christinadobrzyn From https://expensify.slack.com/archives/C02NK2DQWUX/p1723055151068559?thread_ts=1723015261.405329&cid=C02NK2DQWUX, I think we should get full compensation

  19. nkdengineer commented on Dec 24, 2024

    @nkdengineer
    Contributor

    @slafortune friendly bump here

  20. nkdengineer commented on Feb 4, 2025

    @nkdengineer
    Contributor

    @slafortune Please help to check my comment when you have a chance.

  21. slafortune commented on May 8, 2025

    @slafortune
    Contributor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugSomething is broken. Auto assigns a BugZero manager.DailyKSv2EngineeringExternalAdded to denote the issue can be worked on by a contributor

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions