-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Notifications module: Give author (no edit_others_posts) access to specific post via. #273
Comments
@philipjohn @batmoo Do you have thoughts on if this functionality should be added? I'd like to get feedback on this before adding the new functionality but I think we should address the bug in #265 that overlaps with the first part of this ticket. |
Honestly, I'd say this could very easily be a setting in the config somewhere, with the default being the current behavior, as long as #265 is resolved adequately. If we are blocked from subscribing people who won't be able to edit, then this feature (letting them edit) isn't nearly as important, and, indeed, it would be good to make it an explicit choice that the site admin has to make, rather than have it be a default, since the possible outcomes may surprise people (though really, it shouldn't, as what is an admin imagining when they add someone in notifications if not that the person will be able to log in and see the editorial comments?) FWIW I've already figured out the filters needed to enable this feature from external plugin code, so it really could be a "hidden" feature as long as you ensure such/similar code continues to work with the solution to #265. The important thing is that the key incoherency of the current system is fixed. As long as that happens, this feature becomes very optional. That said, I'd still love to see it as a feature, because it is EXTREMELY powerful to use the EF "Subscribers" box as an access delegation tool. We've found it lets us reduce the number of people with |
Oh yeah, I'll add one more thing. I wrote "editor" but that is totally arbitrary. What I really meant was someone with In our particular case, our "editor" role also has Ultimately, I think the best solution would be to create a role like |
Thought about this some more, and I'm thinking this is actually functionality that belongs in its own module. There is more to this than just receiving notifications. The module's purpose would essentially be to give admins/editors the ability to grant edit access to other specific users. These custom accesses could have time limits, or perhaps be cleared when the post is published, etc. The key point being there would be some UI around this behavior, along with a module explaining itself. It could then integrate with notifications and others (CAP?) where it makes sense. This module idea could definitely could use some more brainstorming and planning before jumping into it, but this does feel like the right approach versus trying to bundle in such a feature that's hidden behind notifications. Let me know what you think. We could probably close this out in favor of a Module request issue that more detailing could go into, along with a link here so it's not forgotten to integrate into Notifications. |
Related to #265 (don't allow subscribing users who won't be able to log into post due to insufficient permissions) this would solve the larger problem in a way that feels very natural to the goals of EditFlow.
The key goal is to allow an "editor" (someone with edit_others_posts capability who can thus log into any post and edit it) the ability to add an author (someone without edit_others_posts capability who can thus only edit posts where they are set as author) as an editor of a single post. This could be elegantly combined with the Notifications feature to solve #265 AND souping up the system as a whole.
Example workflow
I know that the roles/capabilities system has granularity down to the post_id in regards to the edit_posts capability, so it would just be a matter of storing a list of user_id's that a post can be edited by regardless of their capabilities (or a list of post_id's that a user can edit, but it seems much more scalable to do it by post rather than by user).
Example Uses
This would be useful in many situations where a site uses the author/editor divide for editorial reasons, but ultimately trusts users to edit others posts in specific situations.
The specific uses are endless, but the key need is the ability to cooperate on posts across the newsroom without having to make almost all users into editors. Keeping the simple interface and non-publishing workflow of the 'author' role is important for many contributors, but fails to account for the nuance that applies to each post.
I think this is a problem Edit Flow is in a prime position to solve because it will integrate so well with the Notifications feature. A theoretical external plugin would need to replicate pretty much the same UI to function, which would be terrible if both were running together.
Thanks for considering it.
The text was updated successfully, but these errors were encountered: