Expensify / App

Welcome to New Expensify: a complete re-imagination of financial collaboration, centered around chat. Help us build the next generation of Expensify by sharing feedback and contributing to the code.
https://new.expensify.com
MIT License
3.23k stars 2.69k forks source link

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

Closed kavimuru closed 2 weeks ago

kavimuru commented 2 months ago

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: 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:

  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?

Screenshots/Videos

https://github.com/Expensify/App/assets/43996225/abeb0194-ab33-48a9-b4b5-e4666ba4ad64

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 OwnerCurrent Issue Owner: @adelekennedy
melvin-bot[bot] commented 2 months ago

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 commented 2 months ago

@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 commented 2 months ago

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

melvin-bot[bot] commented 2 months ago

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

melvin-bot[bot] commented 2 months ago

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

daledah commented 2 months ago

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[bot] commented 2 months ago

πŸ“£ @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. Screen Shot 2022-11-16 at 4 42 54 PM Format:
    Contributor details
    Your Expensify account email: <REPLACE EMAIL HERE>
    Upwork Profile Link: <REPLACE LINK HERE>
eucool commented 2 months ago

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 https://github.com/Expensify/App/blob/1883f99e14194d0d8462955d93c2ad0770a7e8a9/src/libs/PolicyUtils.ts#L153-L155

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[bot] commented 2 months ago

βœ… Contributor details stored successfully. Thank you for contributing to Expensify!

allgandalf commented 2 months ago

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[bot] commented 2 months ago

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

daledah commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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[bot] commented 2 months ago

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

melvin-bot[bot] commented 2 months ago

Triggered auto assignment to @CherylWalsh (Waiting for copy), see https://stackoverflow.com/c/expensify/questions/7025/ for more details.

neil-marcellini commented 2 months ago

Here is the Slack thread where we discussed and landed on a solution. I'm going to re-assign to Danny to give him credit, and since he also proposed some good copy I don't think we need a review from Cheryl, although she's certainly welcome to chime in. I'm going to update the issue description now.

neil-marcellini commented 2 months ago

I'm actually going to go with the proposal from @daledah because it was posted first, makes sense, and he suggested a good alternate solution of editing the copy on the empty categories page. Please take a look at the updated expected results and raise a PR implementing those changes.

melvin-bot[bot] commented 2 months ago

πŸ“£ @allgandalf πŸŽ‰ An offer has been automatically sent to your Upwork account for the Reviewer role πŸŽ‰ Thanks for contributing to the Expensify app!

Offer link Upwork job

melvin-bot[bot] commented 2 months ago

πŸ“£ @daledah You have been assigned to this job! Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review πŸ§‘β€πŸ’» Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs! Keep in mind: Code of Conduct | Contributing πŸ“–

allgandalf commented 2 months ago

@daledah , let us know till when you can come up with the PR, thanks

daledah commented 2 months ago

I'll raise PR today

daledah commented 2 months ago

@allgandalf this PR is ready for review

melvin-bot[bot] commented 1 month ago

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.

melvin-bot[bot] commented 1 month ago

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

laurenreidexpensify commented 1 month ago

hey @adelekennedy handing this one over for my parental leave K2 clear out. we're in the PR stage, so you'll mainly just be handling payments for this one. thanks!

melvin-bot[bot] commented 1 month ago

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

allgandalf commented 1 month ago

friendly bump to @daledah to address this comments, thanks

allgandalf commented 1 month ago

waiting on the contributor to update the platform videos

allgandalf commented 1 month ago

Contributor Updated the PR, will review it today

melvin-bot[bot] commented 1 month ago

@dannymcclain, @neil-marcellini, @adelekennedy, @allgandalf, @daledah Whoops! This issue is 2 days overdue. Let's get this updated quick!

melvin-bot[bot] commented 1 month ago

@dannymcclain, @neil-marcellini, @adelekennedy, @allgandalf, @daledah Eep! 4 days overdue now. Issues have feelings too...

melvin-bot[bot] commented 1 month ago

@dannymcclain, @neil-marcellini, @adelekennedy, @allgandalf, @daledah 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

melvin-bot[bot] commented 1 month ago

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

allgandalf commented 1 month ago

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

melvin-bot[bot] commented 1 month ago

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

melvin-bot[bot] commented 1 month ago

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

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

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

melvin-bot[bot] commented 1 month ago

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 commented 1 month ago

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

Regression Test Proposal

  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 commented 3 weeks ago

[!NOTE] This is due for payment today, thanks :)

adelekennedy commented 3 weeks ago

Payouts due:

adelekennedy commented 3 weeks ago

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

daledah commented 3 weeks ago

@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 commented 3 weeks ago

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

daledah commented 2 weeks ago

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

allgandalf commented 2 weeks ago

not overdue melvin :)

adelekennedy commented 2 weeks ago

thank you @daledah! Offer sent

adelekennedy commented 2 weeks ago

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

adelekennedy commented 2 weeks ago

@daledah bump to accept the offer!