Skip to content
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

Open
jerclarke opened this issue Aug 11, 2014 · 4 comments

Comments

@jerclarke
Copy link
Contributor

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

  • Someone editing a post and wants help from another user
  • Finds user in Notifications metabox, but they are not an editor.
  • Notifications metabox makes it clear they can't be subscribed because they won't be able to see the post.
  • Notifications metabox instead offers a "Grant permission and subscribe"
  • The "author" user is granted permission for the post and added to notifications, the post can now be treated as if they were an editor.

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.

  • Several authors contributing to a post (but no multi-author plugin desired).
  • Summoning a topic expert without edit_others_posts to review the content of a post.
  • Allowing translators to edit specific posts they are translating.

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.

@sboisvert
Copy link
Contributor

@philipjohn @batmoo Do you have thoughts on if this functionality should be added?
I feel like we would need more input from users since it would change current permission levels and perhaps cause unintended consequences. I do think it's a good idea overall but if we add that feature I'd feel more comfortable making a custom capability for it and then maybe giving that to administrators only. Perhaps it's my interpretation of the "editor" role but I don't feel like editor implies being able to give others access to modify content. At least not as a default capability for the plugin.

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.

@jerclarke
Copy link
Contributor Author

jerclarke commented Apr 3, 2018

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 edit_others_posts dramatically, which is a priceless security optimization when you have a large team of contributors who come and go over time.

@jerclarke
Copy link
Contributor Author

Oh yeah, I'll add one more thing. I wrote "editor" but that is totally arbitrary. What I really meant was someone with edit_others_posts, i.e. users for whom this feature is unnecessary.

In our particular case, our "editor" role also has edit_users (as they manage large communities of contributors) and thus even that capability could make sense as the test for whether you can grant_edit_posts.

Ultimately, I think the best solution would be to create a role like grant_edit_posts but design it from the start as a placeholder, with a well-documented filter that replaces it with the capability that best suits the given newsroom. In our situation, we may likely use edit_posts, thus allowing any two authors to collaborate, but for many sites, it could safely remain edit_users and thus block anyone from granting access except "admins" (assuming the default roles).

@WPprodigy
Copy link
Contributor

WPprodigy commented Jan 16, 2020

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.

@htdat htdat changed the title Give author (no edit_others_posts) access to specific post via. Edit Flow/Notifications Notifications module: Give author (no edit_others_posts) access to specific post via. Apr 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants