Voting starts in March for the Drupal Association Board election.
The work being done inwill 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.
- 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:
- 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.
- Create mockups with proposed UI changes
- Implement the changes
User interface changes