-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HOLD for payment 2023-10-16] [$500] Approved requests shouldn't have a delete
option
#26419
Comments
Triggered auto assignment to @NicMendonca ( |
ProposalPlease re-state the problem that we are trying to solve in this issue.
What is the root cause of that problem?
What changes do you think we should make in order to solve the problem?
App/src/components/MoneyRequestHeader.js Line 60 in c9c1f47
App/src/components/MoneyRequestHeader.js Lines 81 to 84 in c9c1f47
Line 749 in 7c13734
What alternative solutions did you explore? (Optional)
For Ref of which options are availableApp/src/components/MoneyRequestHeader.js Lines 85 to 91 in c9c1f47
Updated CodethreeDotsMenuItems={[
...(!isApproved
? [
{
icon: Expensicons.Trashcan,
text: props.translate('reportActionContextMenu.deleteAction', {action: parentReportAction}),
onSelected: deleteTransaction,
},
]
: []),
...restOptions,
]} |
delete
optiondelete
option
Job added to Upwork: https://www.upwork.com/jobs/~01bd5a594a7f989566 |
Current assignees @JmillsExpensify and @NicMendonca are eligible for the External assigner, not assigning anyone new. |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @cubuspl42 ( |
ProposalPlease re-state the problem that we are trying to solve in this issue.Approved requests show a delete option which should not be available What is the root cause of that problem?Currently, we do not have applied conditions to not show delete action in the report header as well in the context menu. What changes do you think we should make in order to solve the problem?I am assuming when the request is settled up, it also gets approved indirectly(which means the approved fields are set to the correct status).
Line 749 in b226893
Line 756 in b226893
At the moment I am not able to test as not having the approved feature/permission for my account. |
@Pujan92 Isn't this feature behind a beta, like most other features? Typically it's enough to manually opt-in by returning |
@Pujan92 Were you able to figure out the beta consideration? |
@jeet-dhandha Did you have any issues with testing the proposed solution? @Pujan92 Also, would you sum up briefly the difference between your proposal and the earlier one? |
No i didn't had any issues. |
@cubuspl42 @JmillsExpensify actually approve button only shows for the corporate policy with manager account id. Now, I am making it true directly and able to test. App/src/components/MoneyReportHeader.js Lines 75 to 80 in 9701fbe
I see that the earlier proposal has been updated laterwards and now it looks quite similar. |
@cubuspl42 Let @Pujan92 have this one 👍 . |
I wanted know how we can allow CORPORATE type Workspace/ |
I don't think we have an option for creating corporate policy. |
Seems incorrect permission or data which we passed to Screen.Recording.2023-09-02.at.15.01.21.mp4Considering that I think it can be tested correctly only on corporate policy. |
Both proposals, in their final form, looked similar and contained convincing root cause analysis and solution plan. Honoring the suggestion by @jeet-dhandha, I say we go with @Pujan92 proposal. At the implementation phase, we'll need to ensure that we have appropriate permissions and capabilities to test the solution thoroughly. C+ reviewed 🎀 👀 🎀 |
@JmillsExpensify I just made a new request of greater than 1 USD and hope now approve button is visible to you. |
Ok great. Looking |
Ok I checked the Onyx for this report. You've set your "principal" and approver as a@a.com. I'm using the volunteer@expensify.com account, but that's only used for payment. So accordingly, I'm not seeing an |
Based on that, I think you have the tools you need to test this yourself. Just make sure that when you sign up using the Teachers Unite form that you have access to both the "teacher" and "principal" emails. At that point, you'll be able to verify your solution works. |
Thanks @JmillsExpensify , I got your point and I believe I can test with having a known "principal" email bcoz it is set as a manager so surely the approve button should be visible in the report. |
@cubuspl42 PR is ready for review! |
Yes exactly. Thank you! |
delete
optiondelete
option
Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:
On to the next one 🚀 |
One of the reasons it took so long is that the issue was related to Teachers Unite / corporate policies, which require extra setup to test. |
delete
optiondelete
option
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.79-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-10-16. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
For reference, here are some details about the assignees on this issue:
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
@cubuspl42 I think we should add a regression test so that this doesn't happen again. Do you agree and mind suggesting one? |
Based on the time between assignment and merge, here's the payment summary:
cc @Julesssss |
I don't have a strong opinion about adding the regression test. Here are the testing steps, if we decide to add one:
|
I don't think this is specific to the TU policy, but instead to all approved requests. That said, I can make those tweaks in the regression test. Now that @Pujan92 has been paid out, I'm going to close this issue. |
While we've already implemented logic preventing
paid
requests from being deleted, the same isn't true forapproved
requests, which we've just added. Accordingly, let's remove theDelete request
option from the three dot overflow menu anytime a request has beenapproved
.Here's mock for clarity. Notice how I've removed the

Delete request
option.Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: