[HOLD for payment 2024-07-24] [$250] Categorizing - Workspace member has option to edit categories, which leads to not here page

[kavimuru]

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: 1.4.82-1
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: Applause internal team
Slack conversation:

Action Performed:

Precondition:

• User is an invited member of a workspace.
• The workspace has disabled all the categories.

1. Go to staging.new.expensify.com
2. Go to FAB > Track expense.
3. Track a manual expense.
4. Click Categorize it from the actionable whisper.
5. Select the workspace that has disabled all the categories.
6. Click Edit categories.

Expected Result:

In Step 6, there should be no option for workspace member to "edit categories". Also, because the member is not an admin, the empty categories page should say this for the title "{workspaceName} doesn't have any categories enabled", and this for the subtext "Categorize this expense by choosing a different workspace, or [ask your admin](link to member's policy expense chat) to enabled categories for this workspace". Lets swap out the Categories button with a "Got it" button which navigates back to the workspace selector.

Here is an example mockup, but we can probably use the existing illustration and only update the text on the page when the member is not an admin.

Here is the Slack thread where this was discussed.

Actual Result:

In Step 6, there is an option for workspace member to "edit categories", which leads to not here page.

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

Bug6511280_1718221633917.20240613_034107.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01693c1a6724bab4ab
• Upwork Job ID: 1801197084944850945
• Last Price Increase: 2024-06-13
• Automatic offers:
• allgandalf | Reviewer | 102782628

Issue Owner

Current Issue Owner: @adelekennedy

[melvin-bot]

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

[kavimuru]

@laurenreidexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

[kavimuru]

We think this bug might be related to #vip-vsb

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01693c1a6724bab4ab

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @allgandalf (External)

[daledah]

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

We always show the edit button here even there are no enabled categories in the WS without checking whether the user is the admin of the WS or not

What changes do you think we should make in order to solve the problem?

We should only show the edit button here if the user is an admin of the WS.

const isAdmin = policy?.role === 'admin';
{isAdmin && (
// Edit button
...
)}

OPTIONAL: If the user is not the admin of the WS, we also can add another description text for the empty state in IOURequestStepCategory to clarify that the user cannot edit categories of this WS

What alternative solutions did you explore? (Optional)

Or we also can hide the workspace option that has no enabled category if the user cannot edit this WS (is not admin of the WS)

[melvin-bot]

📣 @daledah! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[eucool]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Workspace member has option to edit categories, even when they are not admin which leads to not here page

What is the root cause of that problem?

We have condition to show empty categories page which is true if there are no categories in the selected workspace.

This will also show the edit categories page without checking if the current user is the admin or not and as the member of the policy won't have access to edit the categories, they will land on not here page

What changes do you think we should make in order to solve the problem?

We should use the isPolicyAdmin util from PolicyUtils which checks in the employee list of the policy whether the current member is the admin of the workspace or not and then decide to display edit categories if the current user is the admin of the workspace

App/src/libs/PolicyUtils.ts

Lines 153 to 155 in 1883f99

	const isPolicyAdmin = (policy: OnyxInputOrEntry<Policy> | EmptyObject, currentUserLogin?: string): boolean =>
	(policy?.role ?? (currentUserLogin && policy?.employeeList?.[currentUserLogin]?.role)) === CONST.POLICY.ROLE.ADMIN;

Updated code would be:

const isPolicyAdmin = useMemo(() => PolicyUtils.isPolicyAdmin(policy), [policy]);

.
.
.
( isPolicyAdmin &&  <FixedFooter style={[styles.mtAuto, styles.pt5]}>
                        <Button
                            large

What alternative solutions did you explore? (Optional)

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[allgandalf]

Thanks for the proposal everyone!

@codinggeek2023 's proposal looks good to me.

Their RCA is correct and their solution is async with our codebase, we already use isPolicyAdmin util in reports page and workspace initial page

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @neil-marcellini, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[daledah]

@allgandalf Other parts of our codebase also use this condition to check isAdmin like here and here. That's why I used that condition to check admin in the pseudocode.

const isAdmin = policy?.role === 'admin';

So my solution should be chosen because it is the first proposal with the correct RCA and solution. The use of the isPolicyAdmin function in the places mentioned above can be done in the PR phase.

[allgandalf]

@daledah , I suggested the proposal based on current implementation in Workspace pages, I leave the final decision to our internal engineer @neil-marcellini , thanks 🙏

[neil-marcellini]

Thanks for the proposal everyone!

@codinggeek2023 's proposal looks good to me.

Their RCA is correct and their solution is async with our codebase, we already use isPolicyAdmin util in reports page and workspace initial page

🎀👀🎀 C+ reviewed

I like that proposal too, but I think we should go one step further and edit that empty categories page to have different text when a non-admin is viewing it. They don't have the ability to add categories so instead it should explain that the workspace doesn't have any enabled categories, and they should ask an admin to enable some categories or pick a different workspace.

Alternatively we could exclude workspaces without categories from the list, but then users might be confused about why it's missing, so I think it's better to show it. I will start a Slack discussion to make sure we're aligned on the expected behavior.

[daledah]

OPTIONAL: If the user is not the admin of the WS, we also can add another description text for the empty state in IOURequestStepCategory to clarify that the user cannot edit categories of this WS

@neil-marcellini I also mentioned the idea of ​​different text in the main solution.

[melvin-bot]

Triggered auto assignment to @dubielzyk-expensify (Design), see these Stack Overflow questions for more details.

[allgandalf]

Note

False alarm, no regression, the expected result was mentioned with reference to this issue and hence melvin alerted

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.7-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix: Workspace member has option to edit categories #43975

If no regressions arise, payment will be issued on 2024-07-24. 🎊

For reference, here are some details about the assignees on this issue:

• @allgandalf requires payment automatic offer (Reviewer)
• @daledah requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@allgandalf] The PR that introduced the bug has been identified. Link to the PR:
• [@allgandalf] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@allgandalf] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@allgandalf] Determine if we should create a regression test for this bug.
• [@allgandalf] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@adelekennedy] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[allgandalf]

• The PR that introduced the bug has been identified. Link to the PR: N/A

No offending PR really, the piece of code we updated was last touched 2 years back 🫨 , IMO this is a missed implementation detail for whispers categorize action but again hard to deal with as this is an extreme edge case

• A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A

• If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression Test Proposal

• Precondition: User should have an workspace with all categories Disabled:

1. Go to FAB > Track expense.
2. Track a manual expense.
3. In self-DM Click Categorize it from the actionable whisper.

Verify that: the workspace without categories isn't an option

Do we agree 👍 or 👎

[allgandalf]

Note

This is due for payment today, thanks :)

[adelekennedy]

Payouts due:

• Contributor: $250 @daledah (Upwork)
• Contributor+: $250 @allgandalf (Upwork)

[adelekennedy]

@daledah will you share your upwork profile with me so I can extend an offer?

[daledah]

@adelekennedy Sorry I'm having some issue with my Upwork account and is actively resolving it, I'll post an update on it early next week.

[adelekennedy]

let me know @daledah I'll keep this issue open for now

[daledah]

@adelekennedy All good now! Please help send an offer to my profile https://www.upwork.com/freelancers/~0138d999529f34d33f

[allgandalf]

not overdue melvin :)

[adelekennedy]

thank you @daledah! Offer sent

[adelekennedy]

https://www.upwork.com/nx/wm/client/contracts?contractStatus=pending&contactPerson=1004801002

[adelekennedy]

@daledah bump to accept the offer!

[daledah]

@adelekennedy I did it, thanks for the kind bump

[adelekennedy]

payment made! Closing this