Closed kavimuru closed 2 weeks 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.
@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.
We think this bug might be related to #vip-vsb
Job added to Upwork: https://www.upwork.com/jobs/~01693c1a6724bab4ab
Triggered auto assignment to Contributor-plus team member for initial proposal review - @allgandalf (External
)
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
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
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)
π£ @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:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>
Workspace member has option to edit categories, even when they are not admin which leads to not here page
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
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
β Contributor details stored successfully. Thank you for contributing to Expensify!
Triggered auto assignment to @neil-marcellini, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@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.
@daledah , I suggested the proposal based on current implementation in Workspace pages, I leave the final decision to our internal engineer @neil-marcellini , thanks π
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.
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.
Triggered auto assignment to @dubielzyk-expensify (Design
), see these Stack Overflow questions for more details.
Triggered auto assignment to @CherylWalsh (Waiting for copy
), see https://stackoverflow.com/c/expensify/questions/7025/ for more details.
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.
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.
π£ @allgandalf π An offer has been automatically sent to your Upwork account for the Reviewer role π Thanks for contributing to the Expensify app!
π£ @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 π
@daledah , let us know till when you can come up with the PR, thanks
I'll raise PR today
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.
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.
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!
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.
friendly bump to @daledah to address this comments, thanks
waiting on the contributor to update the platform videos
Contributor Updated the PR, will review it today
@dannymcclain, @neil-marcellini, @adelekennedy, @allgandalf, @daledah Whoops! This issue is 2 days overdue. Let's get this updated quick!
@dannymcclain, @neil-marcellini, @adelekennedy, @allgandalf, @daledah Eep! 4 days overdue now. Issues have feelings too...
@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!
β οΈ 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.
[!NOTE] False alarm, no regression, the expected result was mentioned with reference to this issue and hence melvin alerted
Reviewing
label has been removed, please complete the "BugZero Checklist".
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:
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:
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
[x] 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
[x] 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.
Verify that: the workspace without categories isn't an option
Do we agree π or π
[!NOTE] This is due for payment today, thanks :)
Payouts due:
@daledah will you share your upwork profile with me so I can extend an offer?
@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.
let me know @daledah I'll keep this issue open for now
@adelekennedy All good now! Please help send an offer to my profile https://www.upwork.com/freelancers/~0138d999529f34d33f
not overdue melvin :)
thank you @daledah! Offer sent
@daledah bump to accept the offer!
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:
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
Issue Owner
Current Issue Owner: @adelekennedy