Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
6 tasks done
lanitochka17 opened this issue May 23, 2024 · 47 comments
Assignees
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor

Comments

@lanitochka17
Copy link

lanitochka17 commented May 23, 2024

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: 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 OwnerCurrent Issue Owner: @mallenexpensify
@lanitochka17 lanitochka17 added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels May 23, 2024
Copy link

melvin-bot bot commented May 23, 2024

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
Copy link
Author

@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
Copy link
Author

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

@cretadn22
Copy link
Contributor

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
Copy link
Contributor

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.

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)

@mallenexpensify mallenexpensify added the External Added to denote the issue can be worked on by a contributor label May 24, 2024
@melvin-bot melvin-bot bot changed the title Categorizing- Workspace chat under To field opens not here page when new WS is not created yet [$250] Categorizing- Workspace chat under To field opens not here page when new WS is not created yet May 24, 2024
Copy link

melvin-bot bot commented May 24, 2024

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

@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label May 24, 2024
Copy link

melvin-bot bot commented May 24, 2024

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

@mallenexpensify
Copy link
Contributor

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
Copy link
Contributor

tienifr commented May 25, 2024

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

tienifr commented May 28, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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

Copy link

melvin-bot bot commented May 30, 2024

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

Copy link

melvin-bot bot commented May 31, 2024

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

@melvin-bot melvin-bot bot added Overdue and removed Help Wanted Apply this label when an issue is open to proposals by contributors labels Jun 3, 2024
@rojiphil
Copy link
Contributor

rojiphil commented Jul 3, 2024

is the PR awaiting your review again?

Yes. Will review today.

Copy link

melvin-bot bot commented Jul 8, 2024

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

Copy link

melvin-bot bot commented Jul 10, 2024

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

@tienifr
Copy link
Contributor

tienifr commented Jul 11, 2024

PR reached production yesterday.

Copy link

melvin-bot bot commented Jul 12, 2024

@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
Copy link
Contributor

Melvin, The PR is on production now

@melvin-bot melvin-bot bot added Weekly KSv2 Awaiting Payment Auto-added when associated PR is deployed to production and removed Daily KSv2 labels Jul 15, 2024
@melvin-bot melvin-bot bot changed the title [$250] Categorizing- Workspace chat under To field opens not here page when new WS is not created yet [HOLD for payment 2024-07-22] [$250] Categorizing- Workspace chat under To field opens not here page when new WS is not created yet Jul 15, 2024
@melvin-bot melvin-bot bot removed the Overdue label Jul 15, 2024
Copy link

melvin-bot bot commented Jul 15, 2024

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:

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

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

Copy link

melvin-bot bot commented Jul 15, 2024

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
Copy link
Contributor

  • [@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

Copy link

melvin-bot bot commented Jul 25, 2024

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

@mallenexpensify
Copy link
Contributor

mallenexpensify commented Jul 26, 2024

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

@melvin-bot melvin-bot bot added Overdue and removed Overdue labels Jul 26, 2024
@rojiphil
Copy link
Contributor

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

@mallenexpensify Offer accepted. Thanks

Copy link

melvin-bot bot commented Jul 30, 2024

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

@mallenexpensify
Copy link
Contributor

@rojiphil paid! Updated payment comment above.

@JmillsExpensify
Copy link

$250 approved for @tienifr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor
Projects
No open projects
Status: Done
Development

No branches or pull requests