Per-problem permissions

[edemaine]

I've already wanted to be able to give a user access to a specific problem (or set of problems) within a group. I think a clean way to do this is for each problem (root message) to have a special list of users and permissions (in the same style as groups, but for problems too). This will require some care in the message publication, to send the groups you have full access to as well as the messages (and their descendants, findable via root) that you have specific access to. Also need a Users UI for messages not just groups (/group/users/messageID). Should be doable and very useful.

[edemaine]

New plan: [problem = root message]

• Each user can have roles in specific problems, not just groups. Unclear whether these problems should be rendered as belonging to their original group, or to a special "externals" group.
• Each group can have roles in specific problems. The permission of a user in the problem is then the AND of their permission in that group with the permission of the group in the problem. These are presumably rendered within the new group (as well), but maybe with a note that it's from another group. URL can refer to new group.

[edemaine]

More generally, we'd like to have threads that don't belong to a group, but are "one off". A hack for this is to have one "Miscellaneous" group which no one "belongs" to per se, but people get access to individual threads. (Important then that users can administer threads, not just groups. And maybe need the ability for users to add new threads to Miscellaneous group...)

We could also imagine a broader model where a thread can belong to multiple groups (have multiple group permissions), or possible none, in addition to having access from multiple users. Like AFS permissions.

At the top level, you could see what groups you have access to, and what individual messages you have access to. (An alternative to presenting the groups the messages came from, but present a partial view of it.) In general the group model is getting a bit stretched... need to rethink.

[Discussion with Stefan]

[edemaine]

#42 would be a nice way to give people access without knowing their username (and e.g. when they don't have an account yet).

[edemaine]

Groups will need the notion of "guest members" (at least internally, maybe displayed in the list of people who have access to a thread) that don't have global group access, but have access to at least one thread in the group, and thus need to be considered for email notifications etc.

[make-github-pseudonymous-again]

Groups could be like tags. They can be added to and removed from threads. One can list all threads belonging to some group by clicking on this group "tag". Some users would have access to the thread via group permissions. Others by invitation. A search bar would allow to filter through raw text, group tags and general tags (e.g. \Omega group:compgeom tag:reduction)

Do tags currently belong to groups?

[edemaine]

At long last, we have per-thread permissions! I went for a relatively simple approach, allowing admins to click "Users" at the thread level, and getting permissions specific to that thread. These users are considered "partial members" of the group; they get access to the user list, to any threads they have access to, and the group appears in their list of groups (a special sublist on the front page). You could also e.g. give someone access to read the entire group (via group permissions) and give them access to edit a specific thread (via thread permissions).

This wasn't as hard as I expected, but it was still a lot of work. Check out dfee190 if you're interested.