[$500] Deeplinks - Public room conversation opened when tapped on user share profile deeplink

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 1.3.98.0
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:

1. Open app
2. Sign Out
3. Paste this link in other app (messenger or notes) https://staging.new.expensify.com/r/3504895439653267
4. Click on the deeplink from previous step
5. Once app opened and public room displayed as a guest click on Sign In button
6. Sign In with valid account
7. Click back button to navigate to LHN
8. Kill the app
9. Paste this link in other app (messenger or notes) https://staging.new.expensify.com/a/15548487
10. Click on the deeplink from previous step

Expected Result:

User profile should be displayed

Actual Result:

Public room conversation opened

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6272582_1699719100290.screen-20231111-025147.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01f7fa12128d4cc313
• Upwork Job ID: 1723394105381797888
• Last Price Increase: 2023-11-11

[melvin-bot]

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

[melvin-bot]

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

[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

[melvin-bot]

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

[erquhart]

Related, maybe same rca: #31150

[bernhardoj]

Proposal

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

A previously visited public room is opened after reopening the app (no need to open the profile page).

What is the root cause of that problem?

When we open a public room while logged out and then press the "Sign in" button, it will navigate the user to the sign-in modal and set LAST_OPENED_PUBLIC_ROOM_ID onyx to be the public room reportID.

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

Lines 105 to 111 in ffe1c63

	Navigation.navigate(ROUTES.SIGN_IN_MODAL);
	Linking.getInitialURL().then((url) => {
	const reportID = ReportUtils.getReportIDFromLink(url);
	if (reportID) {
	Onyx.merge(ONYXKEYS.LAST_OPENED_PUBLIC_ROOM_ID, reportID);
	}
	});

After we reopen the app, AuthScreen will be mounted and it will check if there is a LAST_OPENED_PUBLIC_ROOM_ID, then open it (and clear the LAST_OPENED_PUBLIC_ROOM_ID).

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

Lines 204 to 207 in ffe1c63

	if (lastOpenedPublicRoomID) {
	// Re-open the last opened public room if the user logged in from a public room link
	Report.openLastOpenedPublicRoom(lastOpenedPublicRoomID);
	}

App/src/libs/actions/Report.js

Lines 2203 to 2208 in ffe1c63

	function openLastOpenedPublicRoom(lastOpenedPublicRoomID) {
	Navigation.isNavigationReady().then(() => {
	setLastOpenedPublicRoom('');
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(lastOpenedPublicRoomID));
	});
	}

The "open the last public room" logic is required when the sign-in page is not a modal yet. When we open a public room, we are signed in as an anon user. In the initial implementation, pressing the "Sign in" button will sign you out, so the AuthScreen is unmounted and the full sign-in page is shown, so the public room page is lost and we want to reopen it back after login.

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

Because now we open the sign-in modal, we can remove the last open public room id logic as it's not needed anymore.

[dukenv0307]

Proposal

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

Public room conversation opened

What is the root cause of that problem?

In here, we'll navigate the user to the last opened public room after the user sign in. This logic is needed (still now) in case the user click "Sign in" in footer, terminate and reopen the app, it should still show the correct public room after sign in.

We set the last opened room id from here. But the signOutAndRedirectToSignIn is called in a lot of places as a side effect, not just when pressing "Sign in"

This issue happens because of a race condition, the logic to navigate and reset room id is called first, then the signOutAndRedirectToSignIn is run, setting the public room id again, causing the issue.

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

We need to clear the public room id after the user session auth status changes from "anonymous" to "not anonymous", to make sure the public room id is cleaned up properly after signed in. We can add here

if (val?.authTokenType !== 'anonymousAccount') {
    setLastOpenedPublicRoom(null);
}

(or using the isAnonymousUser method)

What alternative solutions did you explore? (Optional)

Extract the setting of the public room id here to a separate function, and only call it upon user interactions like clicking on "Sign in", not putting it in signOutAndRedirectToSignIn any more (which also is run as clean-up side effects and cause problems similar to this issue)

[sudhakar-s]

Please re-state the problem that we are trying to solve in this issue.
Universal deeplinking for profile page

What is the root cause of that problem?

Noticed that as of today, current implementation for universal linking seems to be only supporting chat report and no other pages(Ref). so links starts with https://*.new.expensify aka universal linking only supports chat report which may not be the case for traditional deeplinking(starts with new-expensify://*).

Addressing this issue might mean, setting up universal deeplinking support similar to linkingConfig by extending Linking.getInitialURL().

What should be the next step here if this is known limitation?

[melvin-bot]

📣 @sudhakar-s! 📣
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.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[sudhakar-s]

Contributor details
Your Expensify account email: [email protected]
Upwork Profile Link: https://www.upwork.com/freelancers/~015764c2295330a830

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[greg-schroeder]

You're up here @getusha!

[getusha]

The proposal made by @dukenv0307 looks good and the root cause and the solution makes sense to me!
#31239 (comment)

🎀 👀 🎀 C+ reviewed

[melvin-bot]

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

[bernhardoj]

@getusha may I know why my proposal isn't selected? The last opened public room logic is not needed anymore, so we can remove it.

[bernhardoj]

If you think we still need it because of a case mentioned by @dukenv0307,

This logic is needed (still now) in case the user click "Sign in" in footer, terminate and reopen the app, it should still show the correct public room after sign in.

then I don't agree with it. As explained in my proposal, the initial intention of that logic is

The "open the last public room" logic is required when the sign-in page is not a modal yet. When we open a public room, we are signed in as an anon user. In the initial implementation, pressing the "Sign in" button will sign you out, so the AuthScreen is unmounted and the full sign-in page is shown, so the public room page is lost and we want to reopen it back after login.

So, previously, we reopen the public room because simply it's the last chat/report that we see before sign in as an anonymous user. I don't see why a user would expect to see again the last visited public room after they consciously close the chat or the app.

[dukenv0307]

I don't see why a user would expect to see again the last visited public room after they consciously close the chat or the app.

After closing the app and reopen, if you click back from the login modal, it will open the public room. So if you log in via that modal, it should also open public room. I think that’s what the user’d expect.

Also it’s already working like that currently so if you want to change it it’d be a feature request. Here we should focus on fixing the bug rather than making change to existing behavior.

[bernhardoj]

After closing the app and reopen, if you click back from the login modal, it will open the public room

I really don't understand this. After closing the app and reopening, the LHN will show, even as an anonymous user.

So if you log in via that modal, it should also open public room. I think that’s what the user’d expect.
Also it’s already working like that currently so if you want to change it it’d be a feature request

No behavior is changed, it's already working like that without the last open public room logic because the room is never unmounted in the first place, that's why I suggested removing that logic to avoid unwanted side effect from an unused logic.

@getusha I'm going offline, but please re-evaluate the proposal

cc: @MariaHCD

[dukenv0307]

RPReplay_Final1700066300.mp4

@bernhardoj This is existing behavior, the user will be navigated back to the public report after coming back from the sign in modal (even after closing app and reopen). Your solution will change the behavior (back to LHN) and cause a regression there. Also it’s clear that solution doesn’t fix the root cause.

cc @MariaHCD @getusha

[MariaHCD]

I'll catch up on the discussions here on Monday but can we first confirm if this issue is still consistently reproducible? cc: @kbecciv @mvtglobally can we retest this?

[melvin-bot]

@MariaHCD @greg-schroeder @getusha this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[MariaHCD]

Waiting on @kbecciv to confirm that this is still reproducible.

[kbecciv]

Issue is not reproduced

screen-20231204-223646.mp4

[greg-schroeder]

Okay, perhaps we can close this then?

[getusha]

@greg-schroeder yes, lets close it.

[bernhardoj]

It's still reproducible. The public room still opens after reopening the app.

Screen.Recording.2023-12-08.at.10.26.57.mov

@MariaHCD btw, we have a discussion here to align on what should be the expected behavior.

[getusha]

I think the majority opinion is to do nothing since either way will work https://expensify.slack.com/archives/C01GTK53T8Q/p1700580479451839?thread_ts=1700455132.577509&cid=C01GTK53T8Q https://expensify.slack.com/archives/C01GTK53T8Q/p1700584101131529?thread_ts=1700455132.577509&cid=C01GTK53T8Q when reopening the app, as of this issue it is not reproducible anymore when we open the app from a link to specific page, i'd say to do nothing.

[bernhardoj]

I think only puneet said it's fine either way. The majority voted not to open the public room when reopening the app.

as of this issue it is not reproducible anymore when we open the app from a link to specific page

It still 100% happens.

Screen.Recording.2023-12-08.at.14.20.32.mov

[getusha]

@kbecciv could you please confirm if this is reproducible again?

[bernhardoj]

@kbecciv after the profile page opens, please press back and you will see the public room behind it.

[dukenv0307]

I think the majority opinion is to do nothing since either way will work https://expensify.slack.com/archives/C01GTK53T8Q/p1700580479451839?thread_ts=1700455132.577509&cid=C01GTK53T8Q https://expensify.slack.com/archives/C01GTK53T8Q/p1700584101131529?thread_ts=1700455132.577509&cid=C01GTK53T8Q

I also see everyone voting to keep current behavior 👍

[melvin-bot]

@MariaHCD @greg-schroeder @getusha this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

Current assignee @getusha is eligible for the Internal assigner, not assigning anyone new.

[bernhardoj]

@greg-schroeder hi, it's still reproducible #31239 (comment)

[MariaHCD]

I think the issue is definitely a bit niche and I don't think it's worth the effort to fix it, IMHO. So I agree with @greg-schroeder's decision to close this.

[dukenv0307]

I think the issue is definitely a bit niche

@greg-schroeder Is this why you decided to close this issue?
Or is it because it's no longer reproducible? (Because it's still reproducible)

[dukenv0307]

@greg-schroeder Gentle bump on this