[wp-hackers] User Roles & Capabilities - How come add and edit aren't separate?
erisds at gmail.com
Mon Aug 30 07:43:27 UTC 2010
> Can you explain your use case more? Is this edit-only user only
> editing other people's posts? Editing only her posts that someone else
> writes but assigns to her? Editing both others' posts and his posts?
The specific use case is a user that can edit pages but not add new ones,
but that lead me to look at any similar use case where it might be desirable
to keep add and edit separate and how I would/could solve the problems
However, it probably makes most sense in terms of pages - the idea that an
editor can edit a website's pages but not add new ones.
> > It's also tough to decide how it would be handled. When do we make the
> > switch from requiring add_posts to requiring edit_posts? Someone with
> > add_posts will find themselves suddenly losing their post on save, or
> > publish? Or can they always see it? (In order to see it, they'll need
> > edit_posts to see that screen, right?) The converse is probably also
> > -- someone having the ability to edit_posts but not add_posts... But at
> > point, they can't edit anything unless assigned to them, because they
> > have the capabilities to edit others' posts.
> > It seems like a sensible breakdown but then the implementation gets very
> > foggy.
See, I knew there would be a reason why it isn't done that way, I just
didn't know what it was. It makes sense - it is a very tough line to draw. I
would consider that from the use case of edit but not add then yes they'd
need something like "edit_others_posts", and from the use case of add but
not edit, feasibly they'd need "edit_own_posts" otherwise they'd be locked
out on autosave. But it's a relatively arbitrary line to draw and I wouldn't
imagine these ideas should be built into the default roles - just be *nice*
if the capabilities were there.
> To implement a user with edit_posts but without "add_posts", it might
> be possible to strip a user's edit_posts but give him/her
> edit_others_posts, edit_published_posts, and edit_private_posts as
> appropriate. You'd have do this stripping dynamically, though, since
> menus (in core and in plugins) use edit_posts to control access to
> various screens.
This is where the access system trips me up / starts to make less sense to
me - the fact that the high level capabilites are the ones generally checked
for (so the posts menu checks for edit_posts not edit_posts OR
edit_others_posts etc). But I can see there are ways to work around it (just
change the capability that the menu checks for). There seems to me to be a
few filters missing - e.g. around the add new button on the edit page, but
that's something I can maybe have a go at patching (don't want to be seen as
Anyway, thanks for your replies. My question has been answered - I was only
wondering why it worked that way & now I understand.
More information about the wp-hackers