[HOLD 296932][$1000] Web - Member from Share Somewhere in assign task (creating from group) can choose assignee, results in error

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Create a group
2. Using User A create a task, don't assign it to anybody and leave the default options as it's
3. Log in using User B (member of same group in which task was created)
4. Navigate to task page.
5. Try assigning the user to task ( as User B )
6. Note that a selected user is assigned to task ( but in the network tab shows error error [shown in the recording])
7. Note the assignee is there even we are getting error
8. If we check from User A, assignee is not there

Expected Result:

User B should not be able to assign the task to someone, if they are not a policy admin, the task creator, or a current task assignee.

User B should be able to assign the task to someone if they are a policy admin, the task creator, or the current assignee.

Actual Result:

User B can assign the task to someone when they are not a policy admin, the task creator or current task assignee. However, the assignee only appears in their account and does not appear in user A's (who is the task creator).

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.30-5
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
Notes/Photos/Videos: Any additional supporting documentation

Assignee.bug.in.grp.task.-.Made.with.Clipchamp.1.mp4

Recording.896.mp4

Expensify/Expensify Issue URL:
Issue reported by: @BhuvaneshPatil
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687434560850899

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e2d2c3fd882a94d6
• Upwork Job ID: 1674164051273023488
• Last Price Increase: 2023-06-28

[melvin-bot]

Triggered auto assignment to @joekaufmanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[BhuvaneshPatil]

Proposal

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

Web - Member from Share Somewhere in assign task (creating from group) can choose assignee, results in error

What is the root cause of that problem?

The root cause for this problem is that we are not checking if current user has permission to assign this task to someone.

App/src/components/TaskHeader.js

Lines 66 to 117 in c261901

	<PressableWithFeedback
	onPress={() => Navigation.navigate(ROUTES.getTaskReportAssigneeRoute(props.report.reportID))}
	disabled={!isOpen}
	accessibilityRole="button"
	accessibilityLabel={props.translate('newTaskPage.assignee')}
	hoverDimmingValue={1}
	pressDimmingValue={0.2}
	>
	<View style={[styles.flexRow, styles.alignItemsCenter, styles.justifyContentBetween, styles.pv3]}>
	<View style={[styles.flexRow, styles.alignItemsCenter, styles.justifyContentBetween]}>
	{assigneeAccountID && assigneeAccountID > 0 && (
	<>
	<Avatar
	source={assigneeAvatar}
	type={CONST.ICON_TYPE_AVATAR}
	name={assigneeName}
	size={CONST.AVATAR_SIZE.HEADER}
	/>
	<View style={[styles.flexColumn, styles.ml3]}>
	<Text
	style={[styles.headerText, styles.pre]}
	numberOfLines={1}
	>
	{assigneeName}
	</Text>
	</View>
	</>
	)}
	</View>
	<View style={[styles.flexRow]}>
	{isCompleted ? (
	<>
	<Text>{props.translate('task.completed')}</Text>
	<View style={styles.defaultCheckmarkWrapper}>
	<Icon
	src={Expensicons.Checkmark}
	fill={themeColors.iconSuccessFill}
	/>
	</View>
	</>
	) : (
	<Button
	success
	isDisabled={TaskUtils.isTaskCanceled(props.report) || !TaskUtils.isTaskAssigneeOrTaskOwner(props.report, props.session.accountID)}
	medium
	text={props.translate('newTaskPage.markAsDone')}
	onPress={() => TaskUtils.completeTask(props.report.reportID, title)}
	/>
	)}
	</View>
	</View>
	</PressableWithFeedback>

Currently we are only checking if the task is open or not.

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

• We shall add a condition if the user who is viewing the task page has permission to add the assignee. My guess is that only the creator can assign the task to someone. And disable the PressableFeedback in TaskHeader component.
• We shall add appropriate successData, optimisticData and failureData in setAssigneeValue()
• While disabling the PressableFeedback will do most of work, there may be a case when user directly pastes the url - http://localhost:8080/r/7730858533875691/assignee - This will open TaskAssigneeSelectorModal. To handle this case we shall add condition to the TaskAssigneeSelectorModal to only display if current user has enough permissions.
  i.e wrap with FullPageNotFoundView.
  checks for shouldShow will be -
  !Task.isTaskAssigneeOrTaskOwner - if current user is not assignee or owner.
  !PolicyUtils.isPolicyAdmin - Tif current user is not a policy admin
  ReportUtils.isCompletedTaskReport - If task is completed or not. This will cover - [HOLD for payment 2023-09-21] [$1000] App allows task title update for completed task using deep link and throws error on update #22451
• This is happening in case of accessing task fields like (description, title and assignee) using deep link in case of archived room

Further updates discussed in this comment - #21580 (comment)

What alternative solutions did you explore? (Optional)

None

[joekaufmanexpensify]

I can reproduce this. Based on the design doc, it's not clear to me whether it's expected that anyone in the parent chat can edit a task's assignee.

cc @thienlnam curious if you could share the expected behavior here? Should anyone in the chat be able to edit a task's assignee, or just the task creator/assignee (if there is one).

[thienlnam]

Yes, only the creator, assignee, and policy admins are able to edit a task assignee

[joekaufmanexpensify]

Got it, ty!

[joekaufmanexpensify]

Updated OP to clarify expected behavior.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01e2d2c3fd882a94d6

[melvin-bot]

Current assignee @joekaufmanexpensify is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[namhihi237]

Proposal

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

User B should not be able to assign the task to someone, if they are not a policy admin, the task creator, or a current task assignee.

What is the root cause of that problem?

In TaskHeader we did not check who can open the modal change assign

App/src/components/TaskHeader.js

Line 54 in c122266

const isOpen = props.report.stateNum === CONST.REPORT.STATE_NUM.OPEN && props.report.statusNum === CONST.REPORT.STATUS.OPEN;

App/src/components/TaskHeader.js

Lines 66 to 69 in c122266

	<PressableWithFeedback
	onPress={() => Navigation.navigate(ROUTES.getTaskReportAssigneeRoute(props.report.reportID))}
	disabled={!isOpen}
	accessibilityRole="button"

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

We will check if they are not a policy admin, task creator, or a current task assignee.

1. In TaskHeader.js we will check to disable
2. In TaskAssigneeSelectorModal we will dismiss the modal or update failureData

What alternative solutions did you explore? (Optional)

N/A

[abdulrahuman5196]

@BhuvaneshPatil

While disabling the PressableFeedback will do most of work, there may be a case when user directly pastes the url - http://localhost:8080/r/7730858533875691/assignee - This will open TaskAssigneeSelectorModal. To handle this case we shall add condition to the TaskAssigneeSelectorModal to only display if current user has enough permissions.

What do you suggest to do when user doesn't have enough permissions? Like disable navigate user back or show some errors or disable the selection?

[BhuvaneshPatil]

@abdulrahuman5196 My suggestion would be disable the Options and show error message on the top in red color, that You don't have enough permissions
When I wrote the proposal, my idea was to navigate user back to the task page, but it won't be a good experience for end user.

[abdulrahuman5196]

My suggestion would be disable the Options and show error message on the top in red color, that You don't have enough permissions

@BhuvaneshPatil Could you kindly share any other cases in the app where you have referenced this? Because it would be better if we reuse any existing exception handling behaviour similar to this case?

[BhuvaneshPatil]

@abdulrahuman5196 I will try and find the places where same behavior is being handled.

[BhuvaneshPatil]

@abdulrahuman5196 , similar thing I came across is that when workspace member is trying to access workspace settings page. We show this page -

We can wrap the TaskAssigneeSelectorModal content with - FullPageNotFoundView component. create a new error message (use as subtitleKey) specific for this page and show it.

Example -

App/src/pages/workspace/WorkspaceInitialPage.js

Lines 178 to 182 in aca4e40

	<FullPageNotFoundView
	onBackButtonPress={() => Navigation.goBack(ROUTES.SETTINGS_WORKSPACES)}
	shouldShow={_.isEmpty(props.policy) || !Policy.isPolicyOwner(props.policy)}
	subtitleKey={_.isEmpty(props.policy) ? undefined : 'workspace.common.notAuthorized'}
	>

[joekaufmanexpensify]

Proposals under review

[abdulrahuman5196]

Thanks for the research @BhuvaneshPatil.

I agree with @BhuvaneshPatil 's root cause and solution mentioned here - #21580 (comment)

The addons we should do part of this is,

1. Not just the assign task, title and description fields are also affected, we can add the same check there.
2. Show FullPageNotFoundView if the user tries to directly access the url as mentioned here - [HOLD 296932][$1000] Web - Member from Share Somewhere in assign task (creating from group) can choose assignee, results in error #21580 (comment) (I am also fine with any other exception handling, if we have something already related to tasks but AFAIK currently there is none)

And the condition would be only the creator, assignee, and policy admins are able to edit a task assignee as mentioned here #21580 (comment)

Lets go with the proposal - #21580 (comment)

🎀👀🎀
C+ Reviewed

🎀 👀 🎀 C+ reviewed

[melvin-bot]

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

[abdulrahuman5196]

@namhihi237 Thank you for the proposal. But it is almost similar to the accepted proposal.

[abdulrahuman5196]

@stitesExpensify The C+ approved comment is here #21580 (comment)

[stitesExpensify]

I'm happy to add that in for the front end, but I'm going to tag @thienlnam to make sure that we have this fixed on the backend as well

[Nodebrute]

Proposal

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

Web - Member from Share Somewhere in assign task (creating from group) can choose assignee, results in error

What is the root cause of that problem?

We are not adding any check on who can edit assignee.

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

First we need to add check if isCompletedTaskReport but what is task is not completed yet?
User shouldn't be able to access that page if Task is completed we have few other cases here too.

Task is not completed yet and users who are not allowed to edit assignee can access that page and can edit Task.
Only 3 users are allowed to edit task.
Task Assignee
Task Assigner
Policy Admin

We need to add other checks here too

!Task.isTaskAssigneeOrTaskOwner ---To check if current user is task assignee or task owner if not then user will not be able to access that page.
!PolicyUtils.isPolicyAdmin----To check if current user is policy admin if not then user will not be able to access that page
ReportUtils.isCompletedTaskReport---To check if task is completed then no one should be able to access that page.

I am working on this #22851 PR. I have added all the necessary checks on front end so user cannot access this pages while clicking on them. For accessing these pages using deep links or share some where from front end we can use FullPageNotFoundView using the same checks That I have added here we can stop user from accessing this page.

As no previous proposal has mentioned an effective way of handling this on the frontend, here's another open issue where we are handling all deep links. My proposal was selected there. You can check and decide whether to keep these issues separate or merge them.

What alternative solutions did you explore? (Optional)

[joekaufmanexpensify]

Moving back to weekly as this is on hold.

[joekaufmanexpensify]

Still held on https://github.com/Expensify/expensify/issues/296932

[BhuvaneshPatil]

There are other issues coming in about accessing the pages - #22451, as it was decided to add FullPageNotFoundView - #21580 (comment)

We can handle them here as part of this issue on frontend.
@thienlnam @abdulrahuman5196 I have made the changes in the selected proposal that will fix - #22451

[joekaufmanexpensify]

Still on hold

[BhuvaneshPatil]

@thienlnam @abdulrahuman5196 Suggested proposal doesn't affects backend changes and with very small change solves the new issues as well. If it's fine we can open this issue (make external) and make the changes. Please share your views.

[thienlnam]

I took a look at your proposal and it addresses some cases regarding directly accessing the link. I like your solution, but I'm updating the permission of who can modify a task in this PR, so let's wait until that is done and then we can go with your other changes

[BhuvaneshPatil]

Thanks @thienlnam , similar changes are mentioned in this issue as well - #22451

Please have a look the issue and provide your feedback on the issue because the changes mentioned here are approved on that issue.

[joekaufmanexpensify]

Held

[thienlnam]

Held issue should be merged - we can start looking at solutions for this now #21580 (comment)

[BhuvaneshPatil]

As permissions have changed we will follow the approach that we use for disabling MenuItem/MenuItemWithTopDescription in TaskPreview for hiding (showing FullPageNotFoundView) to following pages -

• TaskDescriptionPage
• TaskTitlePage
• TaskAssigneeSelectorModal

For disabling edits in TaskPreview - we use

App/src/components/ReportActionItem/TaskView.js

Lines 50 to 53 in ab4dc4b

	const isOpen = ReportUtils.isOpenTaskReport(props.report);
	const isCanceled = ReportUtils.isCanceledTaskReport(props.report);
	const canModifyTask = Task.canModifyTask(props.report, props.currentUserPersonalDetails.accountID);
	const disableState = !canModifyTask || !isOpen;

We can use similar logic in FullPageNotFoundView for setting the value for shouldShow attribute.

cc - @abdulrahuman5196

[joekaufmanexpensify]

@thienlnam @BhuvaneshPatil for my own understanding, if anyone that can view a task can now change the task's assignee, what changes do we still need to make in this issue?

[thienlnam]

Yeah good question, the proposal listed is more about better handling edge cases where you aren't able to update task details - a task is cancelled or completed and you try to access the update assignee page directly

[joekaufmanexpensify]

Got it. Is that related to the original bug about a non-assignee being able to update the task assignee? If not, I wonder if it could make sense to open a new bug/new feature issue (depending on which it is), to handle that.

[thienlnam]

Yeah, we can close this - seems like we have a seperate bug for that here #22451

So we can address this specific flow over there

[BhuvaneshPatil]

The selected proposal for the issue mentioned by @thienlnam contains changes that were supposed to be for this issue.

Shall they be added or not?
Because they were considered while selecting the proposal in #22451

[thienlnam]

It looks like the changes you mentioned here are actually covered in the selected proposal message #22451 (comment) regarding use of the FullPageNotFoundView.

So there doesn't seem to be a need to duplicate the changes here

[BhuvaneshPatil]

The proposal selected for that proposal mentions the changes for this issue and these changes were considered for selecting. and this issue was created way earlier, so I want to point out that if the changes are not needed then should not be considered for selection. And if we decide to add those changes, they should not be criteria for deciding.
I have mentioned same there as well but got no response.

This is my proposal for same - #22451 (comment)

[BhuvaneshPatil]

@thienlnam @joekaufmanexpensify

I have found a new bug similar to this one, shall I add them here or wait till they are reported by QA?

[joekaufmanexpensify]

If it's a new bug, it should be handled in a new issue.

[joekaufmanexpensify]

Closing this one for now, since the bug that was specifically covered by this issue was fixed by https://github.com/Expensify/Expensify/issues/296932 !

[BhuvaneshPatil]

Will there be compensation for reporting the bug?

[joekaufmanexpensify]

I would say no, since the need to fix this bug was obviated by internal changes we made in https://github.com/Expensify/Expensify/issues/296932 .

[BhuvaneshPatil]

Okay. Thanks @joekaufmanexpensify