We're trying to allow a more collaborative approach to editing project pages at one of my sites. The project pages are "book" pages with no special fields. (We're not using CCK even.)
So, I set the authenticated role to be able to do the following on the access control table:
* create book pages
* edit book pages (I assume this should mean ANY book page)
* edit own book pages
This role can not:
* create new books or administer the hierarchy.
* or administer nodes
(though while hacking at this I tried granting those privs too and it didn't make a difference).
For some reason a user logged in w/ no other explicit role - e.g. just the authenticated role, can edit SOME book pages authored by other users, but not others. For the life of me I don't see any difference in the data.
Cache is not enabled on this site. Though I truncated the cache_filter table to see if that would fix it. Nope.
Has anybody seen this?
I just upgraded the site to 5.21 in case this was an old bug resolved.
Thanks in advance for your assistance!
Comments
_
Make sure the role has permission to use the input format used on the book pages they can't edit.
THANKS!
That was it.
Extra information for anybody else reading this post trying to diagnose their own problem:
- the fact that it was happening w/ books was a fluke. This issue would have occurred w/ any content type.
- we happened to get some posts with an input format of full html and other posts with filtered html based on how our site evolved. Originally we weren't filtering our html. With experience we shored up our security and changed our configuration to filter all posts. Of course that is set as posts are created. Legacy posts had the non-filtered input format. And since an average user no longer had permission to use that format s/he wasn't allowed to edit those posts. Makes perfect sense.
To fix this, I went back and changed legacy post so use filtered html and bingo, the authenticated user could then edit the posts as set in the permission table.