Jump to:
Issue Summary
Problem/Motivation
The work being done in #731724: Decouple comment.module from node by turning comment settings into a field will result in that comments can be used on any entity just by creating a comment field in the same way as adding a text field. It will also be possible to tailor each comment form used with other fields, making them perfectly adapted for each entity type used on.
But, there is one very big bottleneck that will severely block the usefulness of this new flexibility. That is that permissions are still globally set for all comment forms throughout the same site. This means that it isn't possible to:
- Allow anonymous commenting on blog posts
- Only allow comments for logged in users on articles
- That comments to product must be approved before being visible
To take it further. A site might even need to have different commenting permissions for two different blog content types on the same site.
This permission control isn't just limited to the entity type itself. It should also be possible to override on individual entity items too. For example:
- A blog post offering a giveaway for the right answer could then set the comments to that post to be approved before publishing.
- The writer want to disable comments to a post about a sensitive topic.
This kind of detailed configuration simply isn't possible with global permissions.
Implementing the proposed solution below will not only make the comment module a lot more flexible, it will also give site-owners much more control over their site and who can do what and where.
Proposed resolution
First:
- Remove the global comment viewing/posting permissions completely.
- Split the "Administer comments and comment settings " into two:
- Global comment administration
- Configure comment settings
Then move all the comment viewing/posting permissions to the field configuration. Permissions needed for:
- View
- Post
- Reply (new)
- Skip approval
- Approve comments (new)
- Edit own
- Edit all (new)
Anonymous, authenticated roles will be statically available. All other roles can be manually added to the field. If not added, the permissions for the authenticated is used unless the two new global comment permissions kicks in.
It should also be possible to set the default permissions in the global comment settings. Including adding more roles that then automatically are used for new comment fields.
There will also be a new setting for allowing overriding certain settings on individual items. Such as described in the examples above.
When enabled options are needed for:
- What options can be overridden
- Turn on/off skip approval
- Disable/Enable commenting
- Close/open commenting
- Who can do it
- Item author (overrides the need of the "Approve comments" perm)
- Roles with the "Approve comments" perm
When for example disabling commenting or turning on approval, a custom, overrideable, message should be displayed instead. For example "Comments to this post has been disabled due to ....".
Here too, the global comment admin permission overrides all custom settings.
Remaining tasks
- Create mockups with proposed UI changes
- Implement the changes
User interface changes
TBD
API changes
TBD
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| comment_permissions.png | 5.3 KB | Ignored: Check issue status. | None | None |
Comments
#1
People working on this may be interested in http://drupal.org/node/1903124 and http://drupal.org/node/1903128.
An (apparently) similar discussion to the one reported in the OP happened in #1807776: Support both simple and editorial workflows for translating entities.
#2
@plach This awesome change! Is there any suggestions/ideas about UI for that? Following #1807776: Support both simple and editorial workflows for translating entities I found that UI part is planned for contrib to not mess a permissions page.
I we make #731724-291: Decouple comment.module from node by turning comment settings into a field real so this permissions will be very useful. But I not sure exactly how to apply them to comment-field on per entity/bundle basis
#3
Sort of related #366416: Field Permissions
I think if that gets in this may be obsolete, but I don't consider that likely at this point.
#4
I don't see anything in the OP that you can do in core right now, so don't understand why this is a major task. It sounds like a feature request to me, and most likely one for D9.
#5
This would be a task when #731724: Decouple comment.module from node by turning comment settings into a field lands
#6
@tsvenson once we have agreement on settings for comment form. We can continue here.
Anyway having this global settings currently enough, contrib have field permission and only posting an action that questionable.
I see no reason to introduce this permissions in global scope.
Global
View comments - granularity defined by field
Skip approval - same as now, detailed about anonymous in Form settings
Administer - skip entity access and allows to configure forms.
Approve comments (new) - great idea!
Entity Access
Edit own - entity level
Edit all (new) - entity level
Post comments - global + granularity defined by entity
Reply (new) - useless, It's just a link in formatter (when user allowed to post for the entity type)
#7
Here's a new way to extend access for fields introduced in #1883152: Field level access for EntityNG