Open m-natarajan opened 1 month ago
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.
Job added to Upwork: https://www.upwork.com/jobs/~01bfe746236df54daa
Triggered auto assignment to Contributor-plus team member for initial proposal review - @rayane-djouah (External
)
Edited by proposal-police: This proposal was edited at 2023-10-04 10:15:00.
The message "Waiting for Sara Couto to fix the issue(s)" was still there even after fixing the violation
When we approve/submit money request, we'll generate the optimisticNextStep
to show the user what will happen next:
https://github.com/Expensify/App/blob/2200fd7cf12a0e1b2397eb68faab964a82758759/src/libs/actions/IOU.ts#L6822
https://github.com/Expensify/App/blob/2200fd7cf12a0e1b2397eb68faab964a82758759/src/libs/actions/IOU.ts#L7066
However, when editing amount https://github.com/Expensify/App/blob/2200fd7cf12a0e1b2397eb68faab964a82758759/src/libs/actions/IOU.ts#L5415, we're not doing that. Request edit can also lead to next step change, in case where there's violations and the violations are removed after the edit, and vice versa.
To fix it holistically for all money request update operations,
in here, first we check if the current transaction (before edits) has violations, next we check if the transaction after edit has violations. If the former is true
and latter is false
, that means the violations have been removed as the result of the edit, and the next step should be dependent on the expense report status now instead of "Wait for {user} to fix the issue(s)", so we'll buildNextStep
like here with the status of the current expense report as the predictedNextStatus
, and set it to Onyx just like we did for other flows.
const nextViolationOnyxUpdate = ViolationsUtils.getViolationsOnyxData(
updatedTransaction,
currentTransactionViolations,
!!policy.requiresTag,
policyTagList ?? {},
!!policy.requiresCategory,
policyCategories ?? {},
PolicyUtils.hasDependentTags(policy, policyTagList ?? {}),
);
// no more violation after update
if(currentTransactionViolations.length > 0 && nextViolationOnyxUpdate.value.length === 0) {
const optimisticNextStep = NextStepUtils.buildNextStep(iouReport, iouReport.statusNum ?? CONST.REPORT.STATE_NUM.OPEN)
}
// update to onyx
optimisticData.push(nextViolationOnyxUpdate, {
onyxMethod: Onyx.METHOD.SET,
key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${iouReport?.reportID}`,
value: optimisticNextStep,
})
failureData.push({
onyxMethod: Onyx.METHOD.MERGE,
key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${iouReport?.reportID}`,
value: currentReportNextStep // we can fetch the currentReportNextStep in in Onyx (ONYXKEYS.COLLECTION.NEXT_STEP) beforehand
})
We should at some point handle the case where "There's no violation before, but after edit there's violation", in that case the next step will be "Wait for {user} to fix the issue(s)". I think this is out of scope of this issue for now.
Proposal updated to add notes in the alternative section
@dominictb - I think we should keep the "Wait for {user} to fix the issue(s)" next step message if we have optimistic violations returned from here:
We should change the next step message only if there are current transaction violations and there are no optimistic transaction violations. we need also to restore the next step in case of failure.
Could you please update your proposal and ping me again once it's ready for another review?
We should change the next step message only if there are current transaction violations and there are no optimistic transaction violations. we need also to restore the next step in case of failure.
@rayane-djouah Hey sure that's what I meant by below point in my proposal, let me update with a bit more details in the proposal
we check if the current transaction (before edits) has violations, next we check if the transaction after edit has violations. If the former is true and latter is false
Moving to #wave-control as it's optimistic next steps/violations related. CC: @dangrous @dylanexpensify
assigning myself so I can take a look when proposals are approved!
@dominictb your proposal RCA and solution makes sense to me.
However, to fix the bug for all money request update flows, we need to make the changes in getUpdateMoneyRequestParams
instead of making them only in updateMoneyRequestAmountAndCurrency
function as all the edit money request actions functions (like updateDistanceRequest
, updateMoneyRequestMerchant
, updateMoneyRequestCategory
, updateMoneyRequestTag
...) use the getUpdateMoneyRequestParams
function.
Could you please add a sample code that describes which changes should we make in getUpdateMoneyRequestParams
function?
Will provide an update early tomorrow.
TY!
Adding another BZ - I'll be out until 8/21
Triggered auto assignment to @mallenexpensify (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.
https://github.com/Expensify/App/issues/46914#issuecomment-2273874988 proposal updated!
@dominictb's proposal looks good to me
:ribbon::eyes::ribbon: C+ reviewed
Current assignee @dangrous is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
Yep, looks good to me! I'm wondering - to solve the "There's no violation before, but after edit there's violation" case, could we just do: currentTransactionViolations.length != nextViolationOnyxUpdate.value.length
?
π£ @rayane-djouah π An offer has been automatically sent to your Upwork account for the Reviewer role π Thanks for contributing to the Expensify app!
π£ @dominictb π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
Nice, @dominictb when can we get the PR raised for review?
The PR will be ready by tmr.
Okay so in talking with @mountiny and trying to make this work on the backend, it's going to bog down our code speed and also just be very tricky to do it currently. However! We're in the process of migrating the next steps code, and once that's done we should be able to fix this much more easily.
It does mean in the meantime, though, that we won't want to merge this front-end fix if it will just be overwritten by the backend. So I think this (and the PR, which I'll post on too) will be on hold for the next steps migration to auth. Sorry for the trouble!
This issue has not been updated in over 15 days. @dangrous, @slafortune, @rayane-djouah, @dominictb eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
Still on hold Melvin, don't close this.
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.17-0 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: @saracouto Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1722617920576379
Action Performed:
Expected Result:
Once the user clears the violation, the message should update from "Waiting for Sara Couto to fix the issue(s)" to the corresponding next step
Actual Result:
The message "Waiting for Sara Couto to fix the issue(s)" was still there even after fixing the violation
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
https://github.com/user-attachments/assets/013b1346-7811-4300-a4f7-2d22f153a80d
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @rayane-djouah