Page MenuHomePhabricator

[lib] Allow admins to react and edit messages in sidebars
ClosedPublic

Authored by ashoat on Aug 19 2024, 8:07 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Sep 7, 5:25 AM
Unknown Object (File)
Thu, Sep 5, 10:18 AM
Unknown Object (File)
Sat, Aug 31, 3:38 PM
Unknown Object (File)
Fri, Aug 30, 10:38 PM
Unknown Object (File)
Fri, Aug 30, 3:28 PM
Unknown Object (File)
Fri, Aug 30, 2:39 PM
Unknown Object (File)
Fri, Aug 30, 1:39 PM
Unknown Object (File)
Thu, Aug 29, 9:34 AM
Subscribers
None

Details

Summary

This resolves ENG-9053.

In D13061, I accidentally limited these permissions to top-level (non-sidebar) descendants, instead of granting them for all descendants.

We only need to use TOP_LEVEL_DESCENDANT in cases where we want to restrict the permission for sidebars… for instance, we don't want sidebars to have children, so we use TOP_LEVEL_DESCENDANT for sidebar and subchannel creation permissions.

Test Plan
  1. I set up a repro of the issue in my local environment
  2. I applied this diff to fix the issue
  3. I reset db_version to 67 to trigger migration 68 again
  4. After migration 68 ran again, I confirmed that the issue was gone

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

tomek added inline comments.
lib/permissions/thread-permissions.js
256–257 ↗(On Diff #43459)

Shouldn't this also be DESCENDANT?

This revision is now accepted and ready to land.Aug 20 2024, 1:31 AM
lib/permissions/thread-permissions.js
256–257 ↗(On Diff #43459)

No, this is intentional.

In order to be a member of a sidebar, we require that a user is a member of the parent thread. This is because we don't have a good way to render the sidebar in the inbox UI without the parent thread also being there.

The permission to join a sidebar is granted by the openChildJoinThread permission assigned in getRolePermissionBlobs.