[Due for payment 2025-03-24] [$250] Copilot - Copilot with removed access can still edit profile details

[lanitochka17]

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: 9.0.55-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5140765&group_by=cases:section_id&group_id=229064&group_order=asc
Email or phone of affected tester (no customers): applausetester+gm103221@applause.expensifail.com
Issue reported by: Applause - Internal Team

Action Performed:

Precondition:

1. User A is a main account
2. User B is a copilot with full copilot access
   Steps:
3. As User A navigate to Settings > Security
4. Remove Copilot access for User B
5. As User B try to make some changes in profile section (Add display name, status..)

Expected Result:

Copilot with removed access should not be able to make changes in main account

Actual Result:

Copilot with removed access can still edit profile details to main account

Workaround:

Unknown

Platforms:

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

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6649468_1730215937183.Recording__4438.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021854642791837871459
• Upwork Job ID: 1854642791837871459
• Last Price Increase: 2024-11-07
• Automatic offers:
• nkdengineer | Contributor | 104995797

Issue Owner

Current Issue Owner: @alexpensify

[melvin-bot]

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

[lanitochka17]

@alexpensify 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

[nkdengineer]

Edited by proposal-police: This proposal was edited at 2024-11-08 03:01:39 UTC.

Proposal

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

Copilot with removed access can still edit profile details to main account

What is the root cause of that problem?

The API returns an error as expected but we don't revert the display name or status in failure data

App/src/libs/actions/User.ts

Lines 1262 to 1266 in 3edc346

	API.write(WRITE_COMMANDS.UPDATE_STATUS, parameters, {
	optimisticData,
	});
	}

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

When the access is removed, the account data will be changed like this. So we can use the account data to check whether delegate access has been removed.

1. In AuthScreen, we can add a useEffect to disconnect the delegate access and display a modal

useEffect(() => {
    const isActingAsDelegate = !!account?.delegatedAccess?.delegate;
    const delegates = account?.delegatedAccess?.delegates ?? [];
    const isAccessRemoved = delegates.findIndex((delegate) => delegate.email === session?.email) === -1;

    if (!isActingAsDelegate || !isAccessRemoved) {
        return;
    }
    disconnect();
    // add logic display the modal here

}, [account]);

2. Regarding the modal, we can reuse DelegateNoAccessModal with a bit of customization to change the title/subtitle if necessary. Or we can create a new one based on DelegateNoAccessModal. The design team can confirm the content.

Then add the modal to AuthScreen here

App/src/libs/Navigation/AppNavigator/AuthScreens.tsx

Line 570 in 2fe1a06

<SearchRouterModal />

(the pusher data that the BE should send is something that the contributor would suggest part of his proposal)

3. If these checks aren't enough to check the delegate is removed or not, BE can send a pusher data for account data with a field in delegatedAccess like isCurrentDelegateAccessRemoved. And we can use this field to detect the access is removed.

{
  delegatedAccess: {
      isCurrentDelegateAccessRemoved: true
  }
}

const isActingAsDelegate = !!account?.delegatedAccess?.delegate ?? false;
const delegators = account?.delegatedAccess?.delegators ?? [];

[alexpensify]

Adding to my testing list, I'll review this one soon.

[alexpensify]

No update yet

[melvin-bot]

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