Web - Unable to search room after it has been created

[kbecciv]

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

---

Action Performed:

1. Go to https://staging.new.expensify.com
2. Log in with expensifail account
3. Click on Plus button and Click on New Room
4. On Room name type any name
5. On Workspace select any Workspace
6. Click Create Room
7. After room created type something
8. Go to search box and type the room name which you just created.

Expected Result:

We are able to search for this room using its title.

Actual Result:

Room does not show as an option when we search for it.

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Web

Version Number: 1.1.20-0

Reproducible in staging?: Yes
Reproducible in production?: No

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Video

Expensify/Expensify Issue URL:

Issue reported by: Manan Jadhav & Applause

Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1639336320144000

View all open jobs on GitHub

[OSBotify]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Triggered auto assignment to @NikkiWines (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[mountiny]

I have added two more lines to the PR I already raised to fix other two blockers related to this component to fix this issue as well.

[mountiny]

Actually, just noticed that this has also the and unable to search part, which is not solved in that PR, the linked PR only makes sure the tile name is shown, but one still cannot really search and find the room once you click away from it.

I will split this into two issues then.

[mountiny]

Alright, so I have updated this issue to be only about the inability to search the room after creating it and created separate deploy locker for the room name here as their solutions are not completely connected and it would be better to have a separate PR to solve this as the PR mentioned above is already covering 3 issues (better for testing and granularity).

[mountiny]

Actually, we have found out that this is being worked on by @TomatoToaster. Since the policy rooms are still in beta, full functionality is not required. Internal issue here

[TomatoToaster]

Ok I figured out the source of this problem. When we're creating these policyRooms, somehow they are not being added to the sharedReports table. Typically with chatReports (including defaultRooms), the report has an accountID of 0 and all the members are included in the sharedReports table.

What's happening right now is that the policyRooms have the owner on the report but the report is not shared with them. Here's an example of a policy room, which has no entries in shared reports and a non-zero accountID:

sqlite> select * from reports where reportID = 11179;
   created = 2021-12-13 20:26:33
 submitted =
  approved =
  reportID = 11179
 accountID = 867
 managerID =
reportName = #test_one_more
     state = 0
     total = 0
  currency = USD
cachedData =
    status = 0


sqlite> select * from sharedReports where reportID = 11172;
  accountID = 185
   reportID = 11172
permissions = read, write

  accountID = 867
   reportID = 11172
permissions = read, write

Here's an example of a default chat room with one person in it (#admins room) which organized more correctly:

sqlite> select * from reports where reportID = 11174;
   created = 2021-12-07 20:26:55
 submitted =
  approved =
  reportID = 11174
 accountID = 0
 managerID =
reportName = admins
     state = 0
     total = 0
  currency = USD
cachedData = {"submitted":"","submittedTo":"","approved":"","unapproved":"","reimbursed":"","shared":"","type":"chat","retracted":"","expensify_policyID":"56CD5FB9EB22E916","policyLastModified":1638911442453003,"isSmartReport":false,"cacheComputedBy":867,"inbox":{"violations":[],"policyType":"free","firstSubmittedDate":"","wasComputedInReportCache":true},"reimburserEmail":"__FAKE__","queuedForAutoExport":{"queued":false,"connections":[],"exportFailed":false,"failedConnections":[]},"hasBeenExportedToIntegration":false,"wasReimbursedViaACH":false,"statementCardID":null,"statementPeriodEndDay":null,"isWaitingOnBankAccount":false,"isABAReimbursed":false,"expectedReimbursementDate":null,"canMarkReimbursementReceived":true,"hasReimbursableTotal":false,"hasTransactions":false,"hasBillableTransactions":false,"reportOwners":[],"managerOnVacation":"","isSmartReportOnFile":false,"invoiceID":0,"billID":0}
    status = 0


sqlite> select * from sharedReports where reportID = 11174;
  accountID = 867
   reportID = 11174
permissions = read, write

[TomatoToaster]

You can see from these lines of code:
https://github.com/Expensify/Auth/blob/6fe483924dfa8f4d5356e97cc2fd662e0569b29d/auth/lib/Account.cpp#L2128-L2133

We fetch chat reports that are shared with users NOT chat reports that they own.

[TomatoToaster]

Got a PR for this soon ~ just testing it out locally first.

[TomatoToaster]

Ok so that PR didn't work and herein lies the problem:
https://github.com/Expensify/Auth/blob/c0e21eada76b52827126e2b7d7480cf9ed1032ab/auth/lib/Report.cpp#L402-L406

It seems like we can't really "share" a report with the person who creates it, so maybe we should remove the creator's accountID from the chat report because other chat reports don't tend to have that.

Alternatively we could tweak the fetch chats query to include owned reports, but I think the above solution makes more sense. No other chats seem to be "owned" by users who are in them. This will also allow owners to leave rooms they create if they want to as well.

[TomatoToaster]

I'll work on a CQ to fix this issue for existing chatReports. However, we should run it after the above PR goes into production so that we can capture all chatReports that are made incorrectly in production.

[MelvinBot]

@TomatoToaster Whoops! This issue is 2 days overdue. Let's get this updated quick!

[MelvinBot]

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

[TomatoToaster]

Oh I didn't notice this was overdue because the PR was already merged! I still need to make the query to fix the existing chats. That's not a super pressing issue though so I'll make this a weekly. Going to finish workspace chat docs first.

[TomatoToaster]

This should be fixed as of this PR for new Workspace Chats

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[mvtglobally]

Issue not reproducible during KI retests. (Third week) Closing