[US-17] As a user, I want to comment on a document I can only view (when commenting is enabled), so I can give feedback without edit permissions. #7
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ELFA/rfd#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@Jeremiah mentioned "Google separates this into: Viewer, Commenter, Editor. I think having explicit permission to comment is good". anything to add @niko
[US-17]to [US-17] As a user, I want to comment on a document I can only view (when commenting is enabled), so I can give feedback without edit permissions.I agree with Jeremiah. We should have "commenter" perms. The way i was planning to do it was not with a specific permission for commenting given one by one to users, but more as an option to active on the document (by the editor), if commenting is enabled or not. If enabled, anybody can comment (all the viewers, who have read-only access). I don't know if this is an issue in general or not. What do you say? If commenting option is not active, then nobody can comment.
But we could maintain a whitelist/blacklist of users who are specifically allowed to comment (or banned fro commenting). It would say this whitelisting should be optional. There would be 3 types of commenting :
Why not a "Commenter" role? This seems an established pattern?
I think additive permissions is an easier mental model for people than allowlists and denylists.
A typical document journey: My document is private → My document is shared with a few people with viewer/suggester|commenter/editor permissions → My document is public to view and a few people still have additional permissions
I didn't suggest we shouldn't have the commenter permission. The allowlist is exactly about that and there will be a commenter permission.
I also point out that a document might be in public access without a list of readers, as anybody can read it.
In that case, we might also want anybody to comment. And also a way to ban people from commenting. That will be useful for the social features. It can also be that a social psot is only accessible to some users (readers in ACL) but that all the users who can read, can also comment (and we don't need to double the read permission with a commenter permission) so in that case again, a banlist would be useful, together with the "enabled=true" setting for commenting.