App
App copied to clipboard
Expensify
[HOLD Violations in Auth] RTER Pending Expense - RTER Pending expense is not moved to new report when it's approved
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: v9.0.20-6
Reproducible in staging?: Yes Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://github.com/Expensify/Expensify/issues/403524#issuecomment-2290080995
Email or phone of affected tester (no customers): [email protected]
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause - Internal team Slack conversation:
Action Performed:
Preconditions: a workspace with scheduled submit enabled, a employee and admin and the employee has a company card assigned.
- In an account that has a domain controlled company card (not Expensify Card)
- Submit a expense via scan in the workspace chat
- Wait for the smartscan to finish
- Verify the expense has pending status
- In the workspace chat, submit a manual expense
- Submit the report
- As the approver - Approve the report
Expected Result:
The pending expense should be moved to a new Report.
Actual Result:
The pending expense is not moved to a new report and it still has the Pending Status.
Below are the details of a report with this issue: Account: [email protected] Report ID: 8189390567239041 Transaction ID: 6273679857286185
Workaround:
N/A
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
Triggered auto assignment to @trjExpensify (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.
![melvin-bot[bot] avatar](https://avatars.githubusercontent.com/in/179547?v=4 "Published by a pub.dev verified publisher"){kind=small}
Going to drop off this one, Gents. I'm sure you know what you're doing :)
@JmillsExpensify, @yuwenmemon Whoops! This issue is 2 days overdue. Let's get this updated quick!
After some further discussion in Slack we were conflating this with the other Pending CC Transaction state, which is affecting the customer.
This one might actually benefit from waiting a bit while we get the RTER Violation in Auth (cc @deetergp), since we would be able to keep all logic there and have it be 1:1:1.
Waiting on https://github.com/Expensify/Auth/pull/11972 before implementing this in Auth
@JmillsExpensify, @yuwenmemon Eep! 4 days overdue now. Issues have feelings too...
@JmillsExpensify, @yuwenmemon Eep! 4 days overdue now. Issues have feelings too...
Just a heads up that https://github.com/Expensify/Auth/pull/11972 was deployed to production a few days ago.
Relevant DD section: https://docs.google.com/document/d/1zJqlTe_RajuBtfQYvbMx8PpXgA9CEnUGVyuqZihQ-ok/edit#heading=h.xp9szvgb3nej
Based on this conversation the full ramp-up for violations will take longer than just the implementation of the RTER violation we had been waiting on, so I'm just going to go with the original way we had it in the design doc.
@war-in I'm looking to do something similar to what you and @robertjchen did for Held Requests with this PR (and Issue), except with Expenses that have the "Receipt pending match with card transaction" Violation - are you interested in giving this a look?
I can work on the back-end components for ya.
@yuwenmemon I'm currently involved in HybridApp development but I found someone from our team who can take care of it - @zfurtak :)
I can help with questions if there are any 🫡
Thanks @war-in!
Okay so based on the continuing conversation here, I think ideally we still wait to make the back-end changes until we have Violations fully in Auth. - which seems like it will be a couple of weeks now at the minimum...
That being said, what we'd want to do in the client is treat all transactions with a Pending RTER Violation like they're held. Does that make sense @zfurtak?
Hi 👋 Sorry but I don't have access to the linked chat.
That being said, what we'd want to do in the client is treat all transactions with a Pending RTER Violation like they're held. Does that make sense @zfurtak?
So similarly to the Held Requests, after approving we want to transfer them to to a new report?
hi @isagoico, could you tell me how can I add this card to reproduce the issue? 😊 Or maybe can I use already created account?
Sorry but I don't have access to the linked chat.
Yeah, sorry about that. It's an internal one. In that thread, I was asking about our back-end logic for violations. We're currently in the middle of moving them from one system to another. Based on some recent developments in that discussion, we wanted to hold the back-end changes until that's done.
Now, this puts us at a bit of a crossroads. We can hold off until the back-end is ready to go (maybe about a month, hopefully less) or we can move forward on these front-end portions without being able to reliably test for the moment. Up to us.
As for reproducing, @isagoico I actually don't know how you set that up 😅 - but if you wanted to import a card into your Expensify account you can follow the instructions here: https://help.expensify.com/articles/expensify-classic/connect-credit-cards/Personal-Credit-Cards
@yuwenmemon If this issue is not urgent I would wait for the backend to be ready, as the process of writing frontend code without the backend part is usually slower and may produce some issues due to lack of testing. What do you think? 🤔