[HOLD for payment 2024-07-22] [$250] Categorizing- Workspace chat under To field opens not here page when new WS is not created yet

[lanitochka17]

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.4.75-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: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Track expense
3. Track a manual expense
4. In 1:1 DM, click Categorize it from the whisper
5. Click New workspace
6. Select a category
7. On confirmation page, click on the workspace chat under To field

Expected Result:

Since the workspace chat is not created yet, the workspace chat should be disabled (not clickable)

Actual Result:

The workspace chat is clickable and leads to not here page

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

Bug6489712_1716487367715.bandicam_2024-05-24_01-58-01-499.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c1df32a642cf9a1e
• Upwork Job ID: 1794118174987796480
• Last Price Increase: 2024-05-31
• Automatic offers:
• rojiphil | Reviewer | 102573818
• tienifr | Contributor | 102573820

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

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

[lanitochka17]

We think that this bug might be related to #vip-vsp

[cretadn22]

Proposal

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

Categorizing a workspace chat under the "To" field opens the "Not Here" page when a new workspace has not yet been created

What is the root cause of that problem?

When a new workspace is created, only a draft workspace and draft report are generated. Clicking on the "To" field navigates the app to the report detail page. However, since the report field is undefined at this point (as we have only just created a draft report), this leads to the occurrence of the bug.

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

In the ReportDetailPage, we're utilizing "withReportOrNotFound". Within "withReportOrNotFound", we also need to retrieve the draft report and use it as alternative value when the report is undefined

What alternative solutions did you explore? (Optional)

In the ReportDetailPage, we should acquire both the report and draft report within "withOnyx" and no longer rely on the "withReportOrNotFound" hook. Subsequently, we can verify if the report is undefined, we will utilize the draft report as an alternative value.

[Krishna2323]

Proposal

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

Categorizing- Workspace chat under To field opens not here page when new WS is not created yet

What is the root cause of that problem?

We don't disable to field when the report is a draft policy.

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

We can use ReportUtils.isDraftReport(participant.reportID)) to check if the report is a draft or not and then disable the option.

App/src/components/MoneyRequestConfirmationList.tsx

Line 601 in 791058a

isDisabled: !participant.isInvoiceRoom && !participant.isPolicyExpenseChat && !participant.isSelfDM && ReportUtils.isOptimisticPersonalDetail(participant.accountID ?? -1),

To:

isDisabled:
    !participant.isInvoiceRoom &&
    (!participant.isPolicyExpenseChat || ReportUtils.isDraftReport(participant.reportID)) &&
    !participant.isSelfDM &&
    ReportUtils.isOptimisticPersonalDetail(participant.accountID ?? -1),

What alternative solutions did you explore? (Optional)

[melvin-bot]

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

[melvin-bot]

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

[mallenexpensify]

Was able to reproduce. Seems like it could be external. @rojiphil , if you agree, can you review the proposals above? Thx

2024-05-24_14-27-06.mp4

[tienifr]

Proposal

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

The workspace chat is clickable and leads to not here page

What is the root cause of that problem?

When the report is a draft report, it's not created yet so when we navigate to the ReportDetailsPage by clicking on the To, it will show not found page.

If we look at this, we'll see that the option will be disabled if the participant account is optimistic (&& ReportUtils.isOptimisticPersonalDetail(participant.accountID ?? -1)). This is because we don't want the users to be able to navigate to a page of an optimistic personal detail. It will lead to issues when going online and the real personal detail gets back.

We need to do the same for the draft workspace, if it's a draft workspace then the option should be disabled, because there's no workspace/workspace chat yet. It's just a draft.

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

In here, create a method to check if the participant should be disabled. If the report is a draft report, early return true, if the participant matches this existing condition of optimistic personal detail, also return true

const shouldDisableParticipant = (participant) => {
    if (ReportUtils.isDraftReport(participant.reportID)) {
        return true;
    }

    if (!participant.isInvoiceRoom && !participant.isPolicyExpenseChat && !participant.isSelfDM && ReportUtils.isOptimisticPersonalDetail(participant.accountID ?? -1)) {
        return true;
    }

    return false;
}

Then update this to

isDisabled: shouldDisableParticipant(participant),

One improvement we can make it, when the user hovers on an inaccessible draft report, show a tooltip saying something like "This workspace chat will be created after you submit the expense". There was also a suggestion here that "please do not make it look disabled, because it's not a disabled UI component, its just read-only text". To do this, we need to add the isInteractive prop to the GenericPressable and use it instead of the isDisabled. We already have the same implementation for the button state here and MenuItem here, basically the difference between the isDisabled and isInteractive = false is that for isInteractive = false, the cursor will be the default cursor, not disabled cursor.

There was a proposal above to make ReportUtils.isDraftReport(participant.reportID) an alternate condition for !participant.isPolicyExpenseChat ((!participant.isPolicyExpenseChat || ReportUtils.isDraftReport(participant.reportID))), but it will not fix the issue because the participant.accountID is not optimistic so isDisabled will not be false

What alternative solutions did you explore? (Optional)

For the isInteractive implementation, we can also update BaseListItem or UserListItem so that it only shows default cursor for the avatar part, for the text part, we'll still allow text cursor and the user can copy the text.

An alternative to the isInteractive implementation is, we can simply let the user customize the cursor style of the GenericPressable and pass the prop in from outside. So we'll still use isDisabled but will customize the cursor so it doesn't show disabled cursor.

[rojiphil]

@mallenexpensify @Expensify/Design
I need a reconfirmation on the expected behavior mentioned in the OP as I am not sure if this is intentional.
To me, it looks like we should have created the new workspace and moved ahead instead of restricting the user by disabling(not clickable) workspace chat. This way the user could proceed like any other existing workspace.
What do you think?

[dannymcclain]

To me, it looks like we should have created the new workspace and moved ahead instead

Would love some more thoughts because I wasn't as involved in these convos, but I think you're right about this. To me it seems like we should have already created the workspace by the time they get to the confirmation screen—so clicking on that row would behave just like any other existing workspace. @shawnborton does that sound like where the Slack convos landed?

[shawnborton]

Not entirely sure, but I kind of think we wouldn't create the workspace until the expense is successfully sent there? I don't feel strongly though.

If we do opt for something like that, then I agree, I would just make that workspace row not pressable/hoverable (but please do not make it look disabled, because it's not a disabled UI component, its just read-only text)

[dannymcclain]

Ok yeah that also makes sense to me—because if you back out of this flow then you'd just have a randomly created workspace lingering around.

I would just make that workspace row not pressable/hoverable (but please do not make it look disabled, because it's not a disabled UI component, its just read-only text)

BIG agree with this. 💯

[tienifr]

Proposal updated to address this concern

(but please do not make it look disabled, because it's not a disabled UI component, its just read-only text)

[dubielzyk-expensify]

I would just make that workspace row not pressable/hoverable (but please do not make it look disabled, because it's not a disabled UI component, its just read-only text)

That feels right to me as well

[rojiphil]

Thanks for confirming the expected behaviour here.
So the consensus is not to create a new workspace until expense is successfully requested.

@tienifr proposal LGTM as the proposal not only solves the problem but also addresses the need of not looking like disabled. However, the final UI changes also require the involvement of the design team but this can be taken up in the PR stage.
🎀👀🎀 C+ reviewed

[melvin-bot]

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

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@rojiphil, @mallenexpensify, @hayata-suenaga, @tienifr Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

@rojiphil, @mallenexpensify, @hayata-suenaga, @tienifr 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[tienifr]

PR reached production yesterday.

[melvin-bot]

@rojiphil, @mallenexpensify, @hayata-suenaga, @tienifr Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[hayata-suenaga]

Melvin, The PR is on production now

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.6-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: not found page when select draft policy #43153

If no regressions arise, payment will be issued on 2024-07-22. 🎊

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

• @rojiphil requires payment automatic offer (Reviewer)
• @tienifr requires payment automatic offer (Contributor)

[melvin-bot]

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

• [@rojiphil] The PR that introduced the bug has been identified. Link to the PR:
• [@rojiphil] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@rojiphil] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@rojiphil] Determine if we should create a regression test for this bug.
• [@rojiphil] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@mallenexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[rojiphil]

• [@rojiphil] The PR that introduced the bug has been identified. Link to the PR: Offending PR
• [@rojiphil] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: Added comment
• [@rojiphil] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: Not Required. Existing checklist is good enough to capture such issues.
• [@rojiphil] Determine if we should create a regression test for this bug. : Since we, now, use interactive pattern here (i.e. shown normal cursor instead of disabled cursor), it is better to include regression tests
• [@rojiphil] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Test Steps
1 Create a track expense
2 Perform the action Categorize it
3 Press New workspace
4 Select a category
5 Verify the workspace chat under To field is not pressable and shows normal cursor while hovering over

[melvin-bot]

@rojiphil, @mallenexpensify, @hayata-suenaga, @tienifr Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mallenexpensify]

Contributor: @tienifr due $250 via NewDot
Contributor+: @rojiphil paid $250 via Upwork.

@rojiphil , can you please accept the job and reply here once you have?
https://www.upwork.com/jobs/~01125570305f069950

Test Case

• https://github.com/Expensify/Expensify/issues/415745

[rojiphil]

can you please accept the job and reply here once you have?

@mallenexpensify Offer accepted. Thanks

[melvin-bot]

@rojiphil, @mallenexpensify, @hayata-suenaga, @tienifr Whoops! This issue is 2 days overdue. Let's get this updated quick!

[mallenexpensify]

@rojiphil paid! Updated payment comment above.

[JmillsExpensify]

$250 approved for @tienifr