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
4.03k stars 3.03k forks source link

[Due for payment 2025-02-18] [$500][not here] Prevent "Hmm... It's not here" when logging in by immediately navigating to a report user has access to #55721

Open Beamanator opened 2 weeks ago

Beamanator commented 2 weeks 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!


Reproducible in staging?: Y Reproducible in production?: Y Issue reported by: ? Slack conversation #quality:

Action Performed:

  1. Get a report ID from an existing account A (can be concierge report, or chat, expense, whatever)
  2. Log out of Account A
  3. Navigate to the NewDot report link from above while logged out
  4. Log in with Account B that doesn't have access to that report ^

Expected Result:

I'd expect your most recently accessed report, or maybe even Concierge report, would be open instead of being greeted with "Hmm... it's not here"

Actual Result:

See that after you log in, you immediately are greeted with "Hmm... it's not here"

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~021882791476183455793
  • Upwork Job ID: 1882791476183455793
  • Last Price Increase: 2025-01-28
  • Automatic offers:
    • OmarKoueifi | Contributor | 105922405
Issue OwnerCurrent Issue Owner: @muttmuure
melvin-bot[bot] commented 2 weeks ago

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

melvin-bot[bot] commented 2 weeks ago

Current assignee @muttmuure is eligible for the NewFeature assigner, not assigning anyone new.

melvin-bot[bot] commented 2 weeks ago

:warning: It looks like this issue is labelled as a New Feature but not tied to any GitHub Project. Keep in mind that all new features should be tied to GitHub Projects in order to properly track external CAP software time :warning:

melvin-bot[bot] commented 2 weeks ago

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

melvin-bot[bot] commented 2 weeks ago

Triggered auto assignment to Design team member for new feature review - @shawnborton (NewFeature)

OmarKoueifi commented 2 weeks ago

Contributor details Expensify account email: omar.koueifi@gmail.com Upwork Profile Link: https://www.upwork.com/freelancers/~016c1a735b187cb976

melvin-bot[bot] commented 2 weeks ago

๐Ÿ“ฃ @OmarKoueifi! ๐Ÿ“ฃ 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>
OmarKoueifi commented 2 weeks ago

Contributor details Your Expensify account email: omar.koueifi@gmail.com Upwork Profile Link: https://www.upwork.com/freelancers/~016c1a735b187cb976

melvin-bot[bot] commented 2 weeks ago

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

OmarKoueifi commented 2 weeks ago

Proposal

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

The issue arises when a user navigates to a report they do not have access to (e.g., due to permission issues or the report being restricted). Instead of a smooth fallback mechanism, the user currently sees a message that says: "Hmm... it's not here. You don't have access to this chat".

What is the root cause of that problem?

The root cause lies in the openReportFromDeepLink function in src/libs/actions/Report.ts. After sign-in/sign-up, this function attempts to navigate to the report without first verifying the user's access. Consequently, the app loads the report page, and only then checks permissions, resulting in the error message being displayed.

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

  1. Modify the handleDeeplinkNavigation logic inside waitForUserSignIn().then to include a pre-check for report access:
    • Use const report = getReport(reportID); to fetch the report details.
    • If report is undefined, it indicates the user does not have access to the report.
  2. Implement a fallback mechanism:
    • If the user lacks access, navigate them to a more appropriate screen, such as:
      • The Home Screen
      • The "Recently Accessed Reports" screen
      • The "Concierge Report" (depending on team preference).
    • Ensure valid deep links continue to function as expected for users with the appropriate permissions.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

  1. Public Report Access:
    • Verify that users signing in with a public room link are able to access the report without issues.
  2. Private Report Access:
    • Verify that users signing in with a private room link, which they have permission to access, are able to open the report successfully.
  3. Restricted Access:
    • Verify that users signing in with a private room link, which they do not have permission to access, are redirected to the appropriate fallback screen (e.g., Home Screen or Concierge Report) instead of seeing the error message: "Hmm... it's not here. You don't have access to this chat."

What alternative solutions did you explore? (Optional)

NA

ijmalik commented 2 weeks ago

Proposal

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

Prevent the "Hmm... It's not here" message during login by promptly navigating the user to a report they can access

What is the root cause of that problem?

New requirement

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

Introduce a new prop, redirectLastAccessedReport, in the FullPageNotFoundView component. This prop will handle redirection to the most recently accessed report when enabled.

add following code at https://github.com/Expensify/App/blob/b59f23b37d82a7b3de21a1a75e4c7479e37211f1/src/components/BlockingViews/FullPageNotFoundView.tsx#L64

    if (redirectLastAccessedReport) {
        const lastAccessedReport = findLastAccessedReport(false, false, '');
        const lastAccessedReportID = lastAccessedReport?.reportID;
        const lastAccessedReportRoute = ROUTES.REPORT_WITH_ID.getRoute(lastAccessedReportID);
        Navigation.navigate(lastAccessedReportRoute);
        return null;
    }

And when calling FullPageNotFoundView, pass redirectLastAccessedReport as true for redirection where required

Examples: pass redirectLastAccessedReport prop at 1- https://github.com/Expensify/App/blob/b59f23b37d82a7b3de21a1a75e4c7479e37211f1/src/pages/home/ReportScreen.tsx#L793

redirectLastAccessedReport = {shouldShowNotFoundPage}

2- https://github.com/Expensify/App/blob/5ec2edd20015227d2720975ae47d1b6360b38023/src/pages/iou/request/step/StepScreenWrapper.tsx#L67

<FullPageNotFoundView shouldShow={shouldShowNotFoundPage} redirectLastAccessedReport = {shouldShowNotFoundPage}>

3- https://github.com/Expensify/App/blob/5ec2edd20015227d2720975ae47d1b6360b38023/src/pages/workspace/WorkspaceInitialPage.tsx#L398

redirectLastAccessedReport = {shouldShowNotFoundPage}

4- https://github.com/Expensify/App/blob/5ec2edd20015227d2720975ae47d1b6360b38023/src/pages/workspace/WorkspacePageWithSections.tsx#L180

redirectLastAccessedReport = {shouldShow}

5- https://github.com/Expensify/App/blob/5ec2edd20015227d2720975ae47d1b6360b38023/src/pages/ProfilePage.tsx#L196

<FullPageNotFoundView shouldShow={shouldShowBlockingView} redirectLastAccessedReport = {shouldShowBlockingView}>

6- https://github.com/Expensify/App/blob/5ec2edd20015227d2720975ae47d1b6360b38023/src/pages/ErrorPage/NotFoundPage.tsx#L26

            <FullPageNotFoundView
                shouldShow
                redirectLastAccessedReport

Extend to Other Components Similarly, we can analyze and optimize other components, such as AccessOrNotFoundWrapper, using the same approach applied to FullPageNotFoundView, if necessary.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Automated Test Scenarios To ensure the issue does not reoccur, automated tests should comprehensively cover the following scenario:

Validate that upon login: The application opens either: The most recently accessed report available to the user. Or the Concierge report (as a fallback). Ensure that the user is not greeted with the "Hmm... It's not here" message. This testing ensures proper redirection behavior and eliminates the risk of inaccessible reports disrupting the user experience.

Note: The code will be further optimized during the PR process.

I have tested the following links, and they are functioning correctly after the changes.

55721-testCases-1.txt

Videos:

Before:

https://github.com/user-attachments/assets/3a922fa7-e325-4308-8136-25fbf6000b30

After:

https://github.com/user-attachments/assets/939646a3-b44b-44a3-8151-4bd730652530

Beamanator commented 2 weeks ago

@rushatgabhane looks like you've got a few proposals to review :D

melvin-bot[bot] commented 2 weeks ago

@shawnborton, @Beamanator, @rushatgabhane, @muttmuure Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

melvin-bot[bot] commented 2 weeks ago

โš ๏ธ This issue has had its price increased by 4x or more. Please review the issue and ensure the price is correct.

melvin-bot[bot] commented 2 weeks ago

Upwork job price has been updated to $500

rushatgabhane commented 2 weeks ago

hmm... let me clarify expected outcome here on slack

rushatgabhane commented 2 weeks ago

hellooou! i don't think the above proposals are exactly what we want.

this is the expected outcome -

  1. In incognito, go to any report that is invalid - new.expensify.com/r/1234. this will redirect you to login page.
  2. login
  3. you will now be redirected to r/1234. OpenReport command has returned 404.
  4. so we should now redirect the user to last visited report/path or concierge.

Login is the only case where you should be redirected. If you're already logged in and visit an invalid report, then you should see the 404 page.

cc @ijmalik @OmarKoueifi

ranjan-purbey commented 2 weeks ago

@rushatgabhane how is the "last visited route" determined? Do we store the current route/screen on each navigation for logged-in users? Or did you mean "last visited report"? If so, do we store the last-accessed timestamp for each report?

Also, should this behavior only be applied in case where the user doesn't have permission to view a valid report ID? Or should it also apply for invalid/non-existent report IDs?

rushatgabhane commented 2 weeks ago

i could be wrong, but we only store last visited route. it is stored as a NVP (name value pair) Last_Visited_Path

ranjan-purbey commented 2 weeks ago

i could be wrong, but we only store last visited route. it is stored as a NVP (name value pair) Last_Visited_Path

I believe we can also get the last accessed report using ReportUtils.findLastAccessedReport

OmarKoueifi commented 2 weeks ago

@rushatgabhane

Thanks for clarifying the expected behavior! I believe my proposed solution already aligns with the desired outcome. Let me explain how my changes ensure this:

1. What I did:

I introduced the canAccessReport function within the openReportFromDeepLink logic. This function checks whether the user has access to the report by fetching the report using getReport(reportID) it will returns a boolean.

2. How the logic flows:

3. Why this matches the expected behavior:

https://github.com/user-attachments/assets/0784ea20-19ef-416a-a6c9-5b8fd263971b

https://github.com/user-attachments/assets/a1ed0534-c598-4aff-b180-429f32cf0bfd

https://github.com/user-attachments/assets/542191a8-92e7-4e97-86c6-108ba15a2005

https://github.com/user-attachments/assets/1fa3228e-5a68-4ef7-9cfe-da912454c47f

Additional Clarification

Currently, it seems that the existing behavior (without my code changes) redirects the user to the last report they interacted with or sent a message to. This happens automatically as part of the appโ€™s navigation logic, only when signing in.

Should we keep this behavior, or should we explicitly redirect the user to:

I also tested ReportUtils.findLastAccessedReport(), and it returned the last report the user interacted with, which matches the current behavior. Let me know if we should override this or keep it as is.

rushatgabhane commented 2 weeks ago

give @OmarKoueifi the ๐Ÿ’ฐ already! @Beamanator their proposal LGTM

๐ŸŽ€ ๐Ÿ‘€ ๐ŸŽ€

melvin-bot[bot] commented 2 weeks ago

Current assignee @Beamanator is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

rushatgabhane commented 2 weeks ago

@OmarKoueifi i think we should also add Concierge as a fallback. If findLastAccessedReport is null, then we should take them to concierge.

OmarKoueifi commented 2 weeks ago

Sounds good, will do.

melvin-bot[bot] commented 2 weeks ago

๐Ÿ“ฃ @OmarKoueifi ๐ŸŽ‰ An offer has been automatically sent to your Upwork account for the Contributor role ๐ŸŽ‰ Thanks for contributing to the Expensify app!

Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review ๐Ÿง‘โ€๐Ÿ’ป Keep in mind: Code of Conduct | Contributing ๐Ÿ“–

OmarKoueifi commented 2 weeks ago

The PR will be ready tomorrow end of day or Monday morning, depending on the test results.

melvin-bot[bot] commented 3 days ago

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

melvin-bot[bot] commented 3 days ago

The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.95-6 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 2025-02-18. :confetti_ball:

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

melvin-bot[bot] commented 3 days ago

BugZero Checklist: The PR adding this new feature has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

rushatgabhane commented 2 days ago

This is a new feature. Regression steps:

Test Access When Logged Out and Switching Accounts

  1. On Account A, navigate to any report (e.g., a concierge, chat, or expense report) and note the report ID.
  2. Log out of Account A.
  3. Open the report URL using the noted report ID (e.g., https://staging.new.expensify.com/r/72105063) while logged out.
  4. Log in with Account B, which doesn't have access to the selected report.

Expected Result: The app should redirect to your most recently accessed report (or the Concierge report) rather than displaying "Hmm... it's not here".

Test Access When Already Signed In (Unauthorized Report)

  1. Log in with an account that should not have access to a specific report.
  2. Navigate directly to the report using its link.

Expected Result: The app should display "Hmm... it's not here" to indicate access is not permitted.

Test Access When Already Signed In (Authorized Report)

  1. Log in with an account that has access to a known report.
  2. Navigate to the report using its link.

Expected Result: The report opens normally without any redirection or error messages.