Page MenuHomePhabricator

Better handling for users subscribed to objects they cannot see
Open, Needs TriagePublic

Description

Root issue:

  • We have rolled out spaces internally (and have on the order of 10 in use)
  • Every so often, a task ends up with a subscriber (or even worse, an assignee) who is not actually a member of the space
  • When this happens, there is roughly a "silent failure"
    • Either the user cannot see the task and is unaware; discussion progresses without the user's input or knowledge even though they should be involved
    • The assignee cannot see the task and progress effectively stalls while people assume the task is being worked on while the assignee remains blissfully unaware

It's not a super-frequent occurrence, but it's not super-rare either. It seems to manifest largely in a couple cases:

  • Soliciting input from lower-privileged users (e.g. asking administrative staff for purchasing info)
  • When users are new logical participants in SuperSecretSpaceProject but have not yet been added to the space
  • etc.

It could of course happen with explicit permissions, but seems to occur for us at least mostly with spaces. I suspect part of this is partially because of how strong they are and partially due to there being a default space. Basically, spaces make it easy to add permissions without really thinking about it.

Possible naive solutions:

  • Warn or even disallow when creating the object/changing the permissions
    • This would be somewhat aligned with the existing protections against setting permissions that would lock oneself out of the task
    • It doesn't handle the case where the permissions object itself is changed (i.e. somebody is removed from a space and suddenly can't see the things in that space that they're subscribed to). But that seems like it may be ok; changing membership is a much more explicit action where somebody is deliberately revoking permissions and is thinking actively about permissions.
  • Some sort of reporting for the user who owns the object
    • Similar to above, but maybe more persistent than some dialog at creation time or modification time
    • Maybe along the lines of the setup/timezone warnings?
  • Some way to query objects that are in this state
    • As an admin, I'd be perfectly content with a dashboard panel showing the monogram, the owner, and maybe the disallowed user so that I could chase up anybody who made an object's viewers and permissions irreconcilable.
    • I think this roughly translates just to having a way to query for these case (p is subscribed but p can't see it)
    • I do this right now manually for a few specific Object x (Assignee or Subscriber) x Space groupings that users keep forgetting about

T8953 seems related but not quite the same.

Event Timeline

T4411 discusses some similar issues, although it predates Spaces and focuses on subscribers rather than assignees.