-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Update getSubmitToAccountID with category and tag approver #51196
base: main
Are you sure you want to change the base?
Conversation
@Beamanator We have an issue where the approver for either a tag or a category cannot approve the expense. Screen.Recording.2024-10-22.at.13.16.47.mp4Have we got another rule from the backend regarding approvers for categories or tags? And is it included in the scope of this issue? @nkdengineer I discovered an issue where the selected approver becomes unstable if there’s a value submission error Screen.Recording.2024-10-22.at.13.34.41.mp4 |
Oof good to know! I'll look into this right meow |
@suneox I see in the video after you submit the second time there's no error so I think maybe it's a BE problem. |
Ok so this is all a bit new at the moment (supporting category & tag approvers in NewDot) so we've def got some bugs to work out. Let's try to make each as clear & reproducible as possible so it's easy to resolve them 1 by 1 🙏
|
@Beamanator We can reproduce the issue in this PR after an employee submits an expense has category X that requires approval from approver A on category X, then approver A approve the expense.
The issue happen from second 1:06 -> 1:11 (and 1:32 -> 1:39) approver change from |
@suneox what am I doing different here? Screen.Recording.2024-10-22.at.11.44.46.AM.mov |
I saw some things but again, it's only helpful if you have reproducible steps 🙏 from your video it looked like you clicked around kinda quickly & re-submitted even when you hit some errors instead of refreshing the page. It's useful to refresh to know if the error comes from the backend or the optimistic onyx data |
I’m still trying to reproduce the issue but haven't found the exact steps to consistently reproduce it yet. So i will continue process with checklist and try it later |
FYI I am seeing a bug locally where, when we are forwarding these category reports, initially the report action doesn't show up, but it will after a refresh -> I have a PR up to fix that |
Reviewer Checklist
Screenshots/VideosMacOS: DesktopScreen.Recording.2024-10-22.at.21.00.46.mp4MacOS: Chrome / SafariScreen.Recording.2024-10-22.at.13.11.33.mp4Android: NativeScreen.Recording.2024-10-22.at.21.21.00.mp4Android: mWeb ChromeScreen.Recording.2024-10-22.at.21.16.23.mp4iOS: NativeScreen.Recording.2024-10-22.at.21.09.36.mp4iOS: mWeb SafariScreen.Recording.2024-10-22.at.21.13.23.mp4Warning: Warning: Warning: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change in the priority for selecting the approver LGTM. Regarding the issue I mentioned earlier in the conversation, it seems like it was a backend issue, and I'm now unable to reproduce it.
@nkdengineer would you mind pulling main? I have another backend PR to fix the issue in this flow with the correct / incorrect approver following a category/tag approver - if these work well together, i think we can get this merged soon! |
@Beamanator Just merged. |
const approvalChain: string[] = []; | ||
const reportTotal = expenseReport?.total ?? 0; | ||
|
||
// If the policy is not on advanced approval mode, we should not use the approval chain even if it exists. | ||
if (!PolicyUtils.isControlOnAdvancedApprovalMode(policy)) { | ||
return approvalChain; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh we should probably be getting rule approvers here too & adding them to the approval chain like this:
[...categoryApprovers, ...tagApprovers, ...baseApprovalChain]
(de-duped) 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need to do that here because getSubmitToEmail
will return the submitsTo
as categoryApprover
or tagApprover
if it is matched, and then we get this user's forwardsTo
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm ok so ReportUtils.getApprovalChain
gets called in 2 places so far:
- IOU.approveMoneyRequest
- Here we mainly check
isLastApprover
of the approval chain so it probably doesn't matter adding category/tag approvers to the front of the approval chain - We also call
getNextApproverAccountID
to optimistically figure out who the next manager should be
- Here we mainly check
- IOU.getNextApproverAccountID
- This gets called from buildNextStep and other places (ex: ^)
I thinkkkkk we will see problems if we run some tests with multiple category/tag approvers, because we'll only try to calculate a category/tag approver when submitting, but not as the "next approver" - at least in the optimistic onyx data. (possibly even backend errors, but that's what i'm working on fixing)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nkdengineer can you test my theory ^ there? I can mention exact test steps if you need
Co-authored-by: Alex Beaman <dabeamanator@gmail.com>
@@ -3096,7 +3096,7 @@ function canEditMoneyRequest(reportAction: OnyxInputOrEntry<ReportAction<typeof | |||
} | |||
|
|||
if (policy?.type === CONST.POLICY.TYPE.CORPORATE && moneyRequestReport && isSubmitted && isCurrentUserSubmitter(moneyRequestReport.reportID)) { | |||
const isForwarded = PolicyUtils.getSubmitToAccountID(policy, moneyRequestReport.ownerAccountID ?? -1) !== moneyRequestReport.managerID; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like there's a lint error above (line 1298) where another call to PolicyUtils.getSubmitToAccountID needs to get updated
@nkdengineer just checking in, did you end up testing out #51196 (comment)? |
Details
Update getSubmitToAccountID with category and tag approver
Fixed Issues
$ #51001
PROPOSAL: #51001 (comment)
Tests
Precondition:
CAT_APPROVER
) in ODTAG_APPROVER
) in ODCAT_APPROVER
TAG_APPROVER
CAT_APPROVER
and the second one with the tagTAG_APPROVER
TAG_APPROVER
and the second one with the categoryCAT_APPROVER
Offline tests
Do the same step above and only need to verify that the approver display in the next step is correct.
QA Steps
CAT_APPROVER
TAG_APPROVER
CAT_APPROVER
and the second one with the tagTAG_APPROVER
TAG_APPROVER
and the second one with the categoryCAT_APPROVER
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Screen.Recording.2024-10-22.at.01.42.45.mp4
Android: mWeb Chrome
Screen.Recording.2024-10-22.at.01.40.48.mp4
iOS: Native
Screen.Recording.2024-10-22.at.01.53.12.mp4
iOS: mWeb Safari
Screen.Recording.2024-10-22.at.01.39.50.mp4
MacOS: Chrome / Safari
Screen.Recording.2024-10-22.at.01.34.49.mp4
MacOS: Desktop
Screen.Recording.2024-10-22.at.01.46.46.mp4