App
App copied to clipboard
Removing/Adding a member for workspace isn't reflecting the same member changes on rooms under the same policy
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Issue reported here by @allroundexperts
Action Performed:
- Have a workspace policy. If you don't have one then create one.
- Ensure the policy has atleast 3 members. If not then add members.
- Click the green plus icon -> New room. Select policy from step 1.
- Click on your profile icon -> workspace. Now either remove or add a member.
- Go back and select the policy room chat. Click its icon and select members.
Expected Result:
The policy room chat should have the same member list as the workspace members.
Actual Result:
The policy room chat shows the initial members and not the most recent members
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platform:
Where is this issue occurring?
- Web
- iOS
- Android
- Desktop App
- Mobile Web
Version Number: Reproducible in staging?: Reproducible in production?: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation Expensify/Expensify Issue URL: Issue reported by: Slack conversation:
cc @yuwenmemon, did you work on this feature and if so are you aware of this bug and if there is an open issue about this or something?
Triggered auto assignment to @JmillsExpensify (AutoAssignerTriage
), see https://stackoverflow.com/c/expensify/questions/4749 for more details.
Seems like we would have to update the participants on the associated reports:
https://github.com/Expensify/App/blob/930f18b72829a414ac5e2e19f424871d924eded9/src/pages/ReportDetailsPage.js#L78-L78
I think re: "Optimized API" changes this would mean that we would have something like InviteWorkspaceMember
and RemoveWorkspaceMember
commands that would return partial report data to merge into Onyx with the correct participants.
So we'll need a backend change for sure.
Going to split this into two separate issues as we'll need to tackle "add" and "remove" as separate actions.
Created a couple of sub issues in E/E. They will probably require some engineering team feedback and more discussion. I've left them unassigned for now and put them on HOLD.
Triggered auto assignment to @JmillsExpensify (
AutoAssignerTriage
), see https://stackoverflow.com/c/expensify/questions/4749 for more details.
Whoops, totally missed this one. Thanks @marcaaron for keeping this moving forward. ❤️
This issue has not been updated in over 15 days. @Justicea83 eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
this is currently on hold awaiting on the pattern B detailed section and approval
Releasing this back to the pool as i don't really know when I can take another look
Triggered auto assignment to @puneetlath (AutoAssignerTriage
), see https://stackoverflow.com/c/expensify/questions/4749 for more details.
@puneetlath Huh... This is 4 days overdue. Who can take care of this?
@puneetlath Huh... This is 4 days overdue. Who can take care of this?
@marcaaron does this still need to be on hold. It looks like those two API commands have been refactored based on the linked issues.
I'm not sure tbh. I think a good first step would be to verify if this issue still happens and go from there.
+1 to what marc said.
Ah sorry. I should have clarified that I confirmed this is still happening. Basically just trying to see whether I can go ahead and just treat this as a bug or if it is held on something. Based on what I can see here, it seems like no need to hold and we can just treat it like any other bug.
Ah then yes no need to hold now on anything and we can treat it like any other bug.
@puneetlath Huh... This is 4 days overdue. Who can take care of this?
@puneetlath Eep! 4 days overdue now. Issues have feelings too...
@puneetlath Still overdue 6 days?! Let's take care of this!
Started looking into it.
@puneetlath Eep! 4 days overdue now. Issues have feelings too...
Hey @puneetlath can you provide an update here? I think this is internal and reproducible -- should we throw Demolition
on it to get it moving?
Yep, this is an internal issue I'm working on. The problem is that when we add someone to a policy, they also get shared on certain reports (i.e. the #announce channel). The problem is that when they are shared on the report, we don't push an update to the clients with the updated participants list for that report. So I'm going to update the API to push that to the clients. Should have a PR up by EOW.
Is there a reason this is still open if your PR is on prod @puneetlath ?
Whoops, I assumed this would auto-close. It's done!