User can click on checkbox in public room task

[kavimuru]

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:

• create a public room
• create a task
• copy the link to public room
• open that link in the incognito window
• Observe user can click on checkbox and not redirected to sign in page

Expected Result:

User should be redirected to sign in page as we do in case of title and description

Actual Result:

Checkbox is not disabled and user is not redirected to sign in page

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

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.55-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
Notes/Photos/Videos: Any additional supporting documentation

Recording.1255.mp4

Screen.Recording.2023-08-08.at.12.35.38.PM.1.mov

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

View all open jobs on GitHub

[melvin-bot]

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

[kavimuru]

Proposal by @BhuvaneshPatil

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

User can click on checkbox in public room task but reverting back

What is the root cause of that problem?

We are only checking the following condition to disable checkbox in the TaskPreview component -

App/src/components/ReportActionItem/TaskPreview.js

Line 88 in fdcae9f

disabled={ReportUtils.isCanceledTaskReport(props.taskReport)}

It doesn't check if user is anonymous or not.
Similar to this we don't have any anonymous user check when we click on Title and Description and Assignee in TaskView

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

• For title and description, we redirect user to sign in page, we can follow similar approach here as well
  For that we can use Session.checkIfActionIsAllowed for checkBox.
  We can use

onPress={Session.checkIfActionIsAllowed(() =>isCompleted ? Task.reopenTask(props.report, taskTitle) : Task.completeTask(props.report, taskTitle))}

for CheckBox in TaskView and in TaskPreview
If we don't want to use checkIfActionIsAllowed, we can explicitly check that is session is anonymous when user clicks on checkbox and then redirect user to sign in page.

• another approach (to disable checkbox), We shall add the check if user has permission to modify the task or not.
  at many places we use canModifyTask value to disable the inputs example - in TaskView -
  

  App/src/components/ReportActionItem/TaskView.js

  Lines 50 to 53 in fdcae9f

  	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;

With can modify task, we can add another check if current session is anonymous or not.

App/src/libs/actions/Session/index.js

Lines 87 to 89 in fdcae9f

	function isAnonymousUser() {
	return authTokenType === 'anonymousAccount';
	}

Using above method we can have a check if it's anonymous user or not.
So in TaskPreview we add the check for modifying the task.

const canModifyTask = !Session.isAnonymousUser() && Task.canModifyTask(props.report, props.session.accountID);

And use above variable to disable the checkbox

Similar to above change we can add same in TaskView checkbox. To disable that as well.
we can disable clicking on Title, Description and Assignee in TaskView.

For above approach we will need to pass session using props.

Other places it's implemented using - personalDetails of current user, in that case we need to use withCurrentUserPersonalDetails

We can add similar logic to check if user is anonymous or not at other places to disable inputs in TaskView and HeaderView

What alternative solutions did you explore? (Optional)

[melvin-bot]

@mallenexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mallenexpensify]

@BhuvaneshPatil When I try to test, I keep getting redirected to the login screen and not sent to the report
https://staging.new.expensify.com/r/8185155904730852
and
https://staging.new.expensify.com/r/8902956128353571
were the two links I was trying to access via a private window in Firefox.

Can you test with the above links to see if you can reproduce plz?

[BhuvaneshPatil]

I just checked, this bug was solved recently by some other PR.

#24566

[melvin-bot]

@mallenexpensify Eep! 4 days overdue now. Issues have feelings too...

[mallenexpensify]

Thanks @BhuvaneshPatil
That bug report was from July 16th and yours was from August 8th so compensation isn't due. Closing