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 2023-08-28] [$1000] When deleting a file, there is a space between the username and the '[Deleted message]' #24216

Closed
1 of 6 tasks
kavimuru opened this issue Aug 7, 2023 · 49 comments
Assignees
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. External Added to denote the issue can be worked on by a contributor Reviewing Has a PR in review Weekly KSv2

Comments

@kavimuru
Copy link

kavimuru commented Aug 7, 2023

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. Open a chat.
  2. Send an attachment.
  3. Click on 'Reply in thread.'
  4. Delete the thread file.
  5. Notice the space between username and delete message
  6. Now check that after deleting a text message

Expected Result:

When deleting a file or text message, there should be consistent spacing between the username and the '[Deleted message]'

Actual Result:

When deleting a file, there is a space between the username and the '[Deleted message]' message, causing an inconsistency in spacing compared to deleting a text message.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

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

  • Android / native
  • Android / Chrome
  • iOS / native
  • iOS / Safari
  • MacOS / Chrome / Safari
  • MacOS / Desktop

Version Number: 1.3.50-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
Notes/Photos/Videos: Any additional supporting documentation

screen-recording-2023-08-01-at-33634-pm_OkJMrkI5.1.mp4
Recording.5751.mp4

Expensify/Expensify Issue URL:
Issue reported by: @ayazhussain79
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1690887871347529

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~019a73e78df922007d
  • Upwork Job ID: 1688865815884058624
  • Last Price Increase: 2023-08-08
  • Automatic offers:
    • cubuspl42 | Reviewer | 26111804
    • bernhardoj | Contributor | 26111806
@kavimuru kavimuru added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Aug 7, 2023
@namhihi237
Copy link
Contributor

namhihi237 commented Aug 7, 2023

Proposal

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

When deleting a file or text message, there should be consistent spacing between the username and the '[Deleted message]'

What is the root cause of that problem?

Here is the difference between space after deleting text message and attachment
If it's an attachment, we pass styles.mt2 here

!props.displayAsGroup && isAttachment ? styles.mt2 : undefined,

We have 2 cases:

  • Online => delete => show [Delete message]
  • Offline => delete => keep it intact => online => show [Deleted message]

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

Here we should check more if the attachment has been deleted or not

network: networkPropTypes.isRequired,
 const pendingAction = lodashGet(props.action, 'pendingAction', '');
!props.displayAsGroup &&
    isAttachment &&
    (!ReportActionsUtils.isDeletedAction(props.action) ||
        (props.network.isOffline && ReportActionsUtils.isDeletedAction(props.action) && pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)) ?
    styles.mt2 :
    undefined,
memo(
    ReportActionItem,
    (prevProps, nextProps) =>
    //...
    prevProps.network.isOffline === nextProps.network.isOffline,
),

Result:

  • Online
Screen.Recording.2023-08-08.at.00.36.26.mov
  • Offline
Screen.Recording.2023-08-08.at.00.38.29.mov

What alternative solutions did you explore? (Optional)

N/A

@DanutGavrus
Copy link
Contributor

DanutGavrus commented Aug 7, 2023

Proposal

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

When deleting a file, there is a space between the username and the '[Deleted message]'

What is the root cause of that problem?

In ReportActionItem, we set a top margin if the action is an attachment, but we do not verify that it was not deleted:

!props.displayAsGroup && isAttachment ? styles.mt2 : undefined,

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

We should also verify that:

!props.displayAsGroup && isAttachment && !ReportActionsUtils.isDeletedAction(props.action) ? styles.mt2 : undefined,

What alternative solutions did you explore?

If we want also want to keep the space while waiting for the attachment to be deleted, we should update to:

!props.displayAsGroup && isAttachment && (!ReportActionsUtils.isDeletedAction(props.action) || props.action.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) ? styles.mt2 : undefined,

@melvin-bot
Copy link

melvin-bot bot commented Aug 7, 2023

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

@melvin-bot
Copy link

melvin-bot bot commented Aug 7, 2023

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

@yh-0218
Copy link
Contributor

yh-0218 commented Aug 7, 2023

Proposal

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

When deleting a file, there is a space between the username and the '[Deleted message]'

What is the root cause of that problem?

!props.displayAsGroup && isAttachment ? styles.mt2 : undefined,

Because we have styles.mt2 for all attachments.

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

We have to remove styles.mt2 for only deleted attachments.
We can get deleted status from action ReportActionsUtils.isDeletedAction(props.action).

What alternative solutions did you explore? (Optional)

@bernhardoj
Copy link
Contributor

Proposal

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

After deleting a thread message that is an attachment, the [Deleted Message] still has the margin value that is supposed to be for an attachment only.

What is the root cause of that problem?

When the message is an attachment, we apply a margin-top of 8.

const isAttachment = _.has(props.action, 'isAttachment') ? props.action.isAttachment : ReportUtils.isReportMessageAttachment(message);

!props.displayAsGroup && isAttachment ? styles.mt2 : undefined,

Currently, we check if it's an attachment from the report action isAttachment and ReportUtils.isReportMessageAttachment(message)

isAttachment is a local onyx data that is set when we add a new action/message.

const isAttachment = _.isEmpty(text) && file !== undefined;

isAttachment,

This property is not available on the BE, so if you logout, isAttachment will be lost, and therefore the attachment check will rely on ReportUtils.isReportMessageAttachment(message).

The problem is, when we delete a message, we never set the isAttachment to false. So, the [Deleted message] text will still have the margin-top of 8.

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

Set isAttachment to false when we delete a message.

const optimisticReportActions = {
[reportActionID]: {
pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
previousMessage: reportAction.message,
message: deletedMessage,
errors: null,
linkMetadata: [],
},
};

What alternative solutions did you explore? (Optional)

Remove props.action.isAttachment checks.

@trjExpensify trjExpensify added the External Added to denote the issue can be worked on by a contributor label Aug 8, 2023
@melvin-bot melvin-bot bot changed the title When deleting a file, there is a space between the username and the '[Deleted message]' [$1000] When deleting a file, there is a space between the username and the '[Deleted message]' Aug 8, 2023
@melvin-bot
Copy link

melvin-bot bot commented Aug 8, 2023

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

@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Aug 8, 2023
@melvin-bot
Copy link

melvin-bot bot commented Aug 8, 2023

Current assignee @trjExpensify is eligible for the External assigner, not assigning anyone new.

@melvin-bot
Copy link

melvin-bot bot commented Aug 8, 2023

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

@trjExpensify
Copy link
Contributor

Reproducible, moving this on external! @cubuspl42 you're up! :)

@cubuspl42
Copy link
Contributor

cubuspl42 commented Aug 8, 2023

@namhihi237 I think you're missing a # in your proposal text. Expensify relies heavily on automation, so it's best to stick to templates as closely as possible. Thank you for understanding.

Proposal

@namhihi237
Copy link
Contributor

@cubuspl42 thanks let me update

@cubuspl42
Copy link
Contributor

@yh-0218 Your proposal looks very similar to this one. Is there any additional value?

@cubuspl42
Copy link
Contributor

@bernhardoj I like the direction of your root cause analysis and your "alternative solutions" section.

Remove props.action.isAttachment checks.

Could you elaborate?

@cubuspl42
Copy link
Contributor

@DanutGavrus The essence of your proposal is similar to the one above. Yours is shorter because it skips reasoning about the offline/online state.

Could you comment on this? Are offline/online checks unnecessary in your opinion?

@namhihi237
Copy link
Contributor

I think an offline check is necessary because if no offline check we delete the image, it will remove mt2 even though the image is still showing.

@DanutGavrus
Copy link
Contributor

DanutGavrus commented Aug 8, 2023

@cubuspl42

Yours is shorter because it skips reasoning about the offline/online state.

I was originally thinking that ReportActionsUtils.isDeletedAction(props.action) wouldn't return true before the action was actually deleted, thus it wouldn't return true when deleting an action while offline. It seems I wasn't right.

I'm not sure about slow internet connections in which isOffline returns false, but the call may take quite long to execute. I'm thinking relying only on the pendingAction to be enough while we wait for the attachment to be deleted, regarding the online/offline state. Updated alternate Proposal with that approach if anything.

@bernhardoj
Copy link
Contributor

Could you elaborate?

@cubuspl42 Yes, because the action.isAttachment is a local property, we can remove props.action.isAttachment from here

const isAttachment = _.has(props.action, 'isAttachment') ? props.action.isAttachment : ReportUtils.isReportMessageAttachment(message);

So, the condition will be

const isAttachment = ReportUtils.isReportMessageAttachment(message);

@getusha
Copy link
Contributor

getusha commented Aug 8, 2023

Proposal

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

There is a margin after deleting an attachment.

What is the root cause of that problem?

The external margin is only need for attachments that are not displayed as a group (for attachments that are the first message with avatar and name). Since the margin is applied to a component that renders every type of comment, it will also be applied to the '[Deleted message]' because the message is the first comment and not displayed as a group.

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

We should move the margin and conditions from the current place from here:

!props.displayAsGroup && isAttachment ? styles.mt2 : undefined,

to:
return <RenderHTML html={props.source === 'email' ? `<email-comment>${htmlContent}</email-comment>` : `<comment>${htmlContent}</comment>`} />;

Since the ThumbnailImage will be rendered here, it's the appropriate place to add the margin. We can wrap it with a View and apply the margin based on the conditions.

<View style={[!props.displayAsGroup && props.isAttachment ? styles.mt2 : {}]}>
     <RenderHTML ... />
</View>

What alternative solutions did you explore? (Optional)

@cubuspl42
Copy link
Contributor

@bernhardoj

Yes, because the action.isAttachment is a local property, we can remove props.action.isAttachment from here

If the resulting code is valid, this would be definitely one of the best candidates for a solution. A change consisting solely of code removal is always tempting!

@bernhardoj
Copy link
Contributor

A change consisting solely of code removal is always tempting!

totally agree. Sadly it won't cover the offline case #24216 (comment) 😞

@cubuspl42
Copy link
Contributor

@namhihi237 @DanutGavrus
You provided reasonable and working solutions, but the check for adding the mt2 style becomes complex and difficult to reason about, in my opinion.

@getusha
Thank you very much for exploring this other path! I hoped we could find a clear and neat solution by moving the style to the more inner component, but I don't think this particular proposal achieves that.

@bernhardoj
You focused your attention on the contract of the isAttachment property and the isReportMessageAttachment function, which indeed seems to be close to the essence of this problem.

The attachments have different representations at the time when they're uploaded on the frontend and when they return back from the backend (when they're quite opaquely HTML-encoded). isReportMessageAttachment could be considered a source of truth and isAttachment a local prediction of the future result of isReportMessageAttachment, but available before the backend response is known (also offline). isReportMessageAttachment is false for a deleted message, so it's a clear approach to also falsify isAttachment.

I think we should go with @bernhardoj's proposal, with some minor refactoring which should improve the clarity of the mentioned contracts
C+ reviewed 🎀 👀 🎀

@melvin-bot melvin-bot bot removed the Reviewing Has a PR in review label Aug 21, 2023
@melvin-bot
Copy link

melvin-bot bot commented Aug 21, 2023

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

@melvin-bot
Copy link

melvin-bot bot commented Aug 21, 2023

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.55-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 2023-08-28. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

  • External issue reporter
  • Contributor that fixed the issue
  • Contributor+ that helped on the issue and/or PR

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

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

  • Merged PR within 3 business days of assignment - 50% bonus
  • Merged PR more than 9 business days after assignment - 50% penalty

@melvin-bot
Copy link

melvin-bot bot commented Aug 21, 2023

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:

  • [@cubuspl42] The PR that introduced the bug has been identified. Link to the PR:
  • [@cubuspl42] 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:
  • [@cubuspl42] 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:
  • [@cubuspl42] Determine if we should create a regression test for this bug.
  • [@cubuspl42] 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.
  • [@trjExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

@cubuspl42
Copy link
Contributor

  • The PR that introduced the bug has been identified. Link to the PR:
  • 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:
  • 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:
    • No need for additional discussion
  • Determine if we should create a regression test for this bug.
    • No need for a new regression test
  • 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.
    • N/A

@melvin-bot melvin-bot bot added Daily KSv2 Overdue and removed Weekly KSv2 Daily KSv2 labels Aug 28, 2023
@trjExpensify
Copy link
Contributor

Hey everyone! Sorry for the delay, I've been out of office.

Confirming payments as follows:

  • @bernhardoj - $1,500 for the bug fix & #urgency bonus. - paid!
  • @cubuspl42 - $1,500 for the C+ review & #urgency bonus - paid!
  • @ayazhussain79 - $250 for the bug report. - offer sent.

@melvin-bot melvin-bot bot removed the Overdue label Aug 30, 2023
@ayazhussain79
Copy link
Contributor

@trjExpensify offer accepted, Thank you

@trjExpensify
Copy link
Contributor

Paid!

@bernhardoj
Copy link
Contributor

@trjExpensify Oh no, I think we shouldn't be getting paid yet as we still have a regression here.

(I just realized we haven't linked the regression issue here, my bad)

cc: @cubuspl42

@cubuspl42
Copy link
Contributor

@trjExpensify It's my fault. Do you know how we can clean this up, or should I start a topic on Slack?

I also bumped the PRs that are blocking #25415, I hope we'll soon have this whole thing behind us

@trjExpensify
Copy link
Contributor

Ah, whoops! I've made the payments on those. I think the easiest thing to do is to simply deduct from your next issue bounties. Do you have any in the works you can make a note on to reduce the amount due accordingly?

@bernhardoj
Copy link
Contributor

@trjExpensify I have one that is currently pending for payment #23420

@trjExpensify
Copy link
Contributor

Excellent, commented there.

@cubuspl42
Copy link
Contributor

@trjExpensify Here: #25514

@trjExpensify
Copy link
Contributor

Thanks, commented!

@melvin-bot melvin-bot bot added Reviewing Has a PR in review Weekly KSv2 and removed Daily KSv2 labels Oct 2, 2023
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. External Added to denote the issue can be worked on by a contributor Reviewing Has a PR in review Weekly KSv2
Projects
None yet
Development

No branches or pull requests

10 participants