Closed m-natarajan closed 1 month ago
Current assignee @twisterdotcom is eligible for the Bug assigner, not assigning anyone new.
Triggered auto assignment to @jasperhuangg (AutoAssignerNewDotQuality
)
This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989
So to summarize the linked Slack convo it seems like the unread items that aren't displaying correctly are for automated messages we send (namely this one).
It seems we're not sending the personal details of the new invitee to the account manager when we send the message on their behalf which is preventing the message from displaying correctly in the LHN.
This is a back-end issue.
Based on the code it seems the reproduction steps for this are:
Updating the OP
Hmm I'm unable to reproduce the issue locally based on the reproduction steps I provided above. It appears the personal details for the new invitee are always sent to the account manager, and the LHN item always appears as expected.
@twisterdotcom Do you mind looking over my reproduction steps to see if they make sense? There's a chance that this was just a transient Pusher issue.
We can try to reproduce this again with your account on staging too.
Took a look again, here are the logs from when the automated message should have been sent. They don't really say much in terms of Onyx updates.
We should send the personalDetails from Auth here, gonna add a log to see if that's being hit locally. There's a chance something was wrong when I tried to reproduce it yesterday.
Hmm this time I wasn't able to reproduce exactly the same result as in the OP but the chat does show up as Hidden
which probably isn't what we want.
Strange we're not passing shouldPushOnyxUpdates
here which means we don't push the personal details of the participants when someone creates a chat report via this flow.
Passing true
to that parameter causes the personal details to be pushed out correctly.
I'm guessing we don't call CreateChatReport
normally when creating DMs for NewDot (we use OpenReport which handles pushing those updates separately) which explains why this happens. Since this is all automated in the back-end we don't call OpenReport.
I think a safer bet to just call OpenReport
instead of CreateChatReport
since that's what we call when we create a DM in the front-end anyways.
Opened https://github.com/Expensify/Web-Expensify/pull/43404 which I believe fixes the issue, even though the problem I reproduced wasn't exactly the same as the one in the OP. Regardless it definitely still fixes a bug that I was able to consistently reproduce locally.
@twisterdotcom Do you mind working together on the staging QA of that PR to verify it fixes your problem?
Happy to test on staging. One Q here though is that I wonder whether this also solves the underlying extra problem that this message shouldn't ever be unread for the AM anyway - it's a message from them, so it should always be read by them. It should only become unread once the other participant(s) send a message right?
@twisterdotcom True, that's definitely also an issue. The solution I provided doesn't address that issue, but I can handle that here too.
I wonder if there was some reason we left it this way though? Perhaps if an AM is on #focus mode then we want them to be able to see any new assignments they have, which is why we make it unread for them so it pops up in their LHN?
This isn't a new assignment, it's just a new admin for an existing assignment. We have enough triggers and reports for them to be aware of new assignments, so I don't think this is intended at all. They should not distract from the workload they already have on, so they really should be marked as read by the AM when this message is sent.
Whenever we designed the payload of Onyx data for these AM messages, we must have set the unread flag to true.
But it should be unread for the recipient, not unread for both the sender and recipient
I wonder if there's a comment in the code that will explain if/why we did it this way
I see Rachel Chang in the blame of the notification in the web repo. But the original issue is here:
@twisterdotcom, @jasperhuangg Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@jasperhuangg what do you need to get started on this?
Ah I missed this in my K2 because of the reviewing label, sorry for the delay. It seems I have everything I need to get started, I just wanted to confirm that I wasn't overriding something done on purpose to make these LHN rows unread.
@twisterdotcom, @jasperhuangg Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Got caught up addressing another daily issue today, I should be able to tackle this tomorrow.
Thanks!
A lot has happened in this issue so I just wanted to provide an update on what I'll be working on next.
The original reason this issue was created has been addressed in https://github.com/Expensify/Web-Expensify/pull/43404 (steps 1-6 below). However, there were concerns that the admin invite notification should not show as unread for the AMs since they are the ones sending the message (step 7 below)
So we basically want the following expected behavior:
./script/clitools.sh generator:domain
for that account.Hey there! Dropping by to ....
.@twisterdotcom, @jasperhuangg Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
https://github.com/Expensify/Web-Expensify/pull/43659 is on prod, I think it should be safe to close this out!
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: Reproducible in staging?: Needs reproduction Reproducible in production?: Needs reproduction 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: @twisterdotcom Slack conversation: https://expensify.slack.com/archives/C05LX9D6E07/p1725028457379559
Action Performed:
Expected Result:
The account manager should see the complete LHN item for the automated message we send on their behalf to the new invitee.
Actual Result:
The account manager sees the incomplete LHN item for the automated message we send on their behalf to the new invitee.
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Onyx data for messages not clicked:
Onyx Data for messages clicked:
Add any screenshot/video evidence
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @jasperhuangg