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.