Posted by eafarris on June 18, 2003 at 1:47pm
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | book.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | TheLibrarian |
| Status: | active |
| Issue tags: | access permissions |
Issue Summary
Collaborative book writing is the single most important thing that drew me to Drupal.
As our intranet DrupalSite grows, we quickly outgrow the book and moderation permissions. What is needed:
- Fine-grained book permissions, especially with multiple books. We currently have two books, with several more in the works. Each of these books requires a different set of "editors," with almost no overlap. People with the ability to edit one book should not have the ability to edit another. Also with approving changes: the site administrator should be able to give "administer book" privileges to different people based on the book. People allowed to view and rollback changes in one book should not be able to do it for another.
- "Moderate book pages" permission. I'm not ready yet to enable moderation on the whole site wrt stories, comments, and the like, but book content definitely needs moderation. Page changes made by authors needs reviewed before it goes in to the book proper, but i don't want these same people to have to moderate everything, just book revisions.
- Better book revisioning. To make it easier for editors to review book changes, revisions need listed side-by-side (or top-to-bottom) with changes clearly marked. Ideally this could be combined, for example marking new content in red and old content with strikethrough. It is difficult for some editors to review changes to book pages, particularly large ones, when all they have is a "view revision" link that opens the older version as a node.
Comments
#1
Great suggestions eafarris. Your request for Moderation of just books and
not other content types will be available in 4.2. Everything else sounds
good, but isn't currently implemented.
Permissions for each book seems as easy as expanding the _perm() hook to add
read/write/administer permissions for each book and then add access checking
checking for these particular permissions in the _access() hook.
I'll bet that their are freely available php diff tools which will make
revision comparison a snap.
#2
Looks as you might be interested in testing my groups module in contrib/sandbox/killes/groups for your first point.
#3
There's a patch to book.module that attempts to implement per-book permissions in my sandbox:
http://cvs.drupal.org/viewcvs/contributions/sandbox/eafarris/book/?cvsroot=contrib
It's been tested, but not nearly enough.
#4
#5
Since this appears to have stagnated, I took the liberty of picking this up. Here's an updated version that applies to the current cvs. It also has a few improvements over the old version (doesn't throw SQL errors).
#6
Using the book title in the permission name is prone to errors. I'd rather not proceed that way and wait for a (the) new permission system to be implemented.
#7
I am building a v4.4.0 site and would like to include the enhanced book controls discussed in this thread. How do I go about modifying the book module to include the code uploaded by "The Librarian"? Thx.
#8
I think the new book module overhaul includes better permissions. If not, the concepts and code here wouldn't come close to applying anymore anyway.
#9
@Crell: Please quit marking features fixed that aren't. :P
"Fine-grained book permissions, especially with multiple books. We currently have two books, with several more in the works. Each of these books requires a different set of "editors," with almost no overlap. People with the ability to edit one book should not have the ability to edit another. Also with approving changes: the site administrator should be able to give "administer book" privileges to different people based on the book. People allowed to view and rollback changes in one book should not be able to do it for another."
We definitely do *not* have such a thing in the core book module. But, if we in the future abstract book outlines to generic content containers and provide access permissions on those, it would be a huge win.
Pushing to 7.x.
#10
I thought that was added? Or was it considered and didn't make it? Bah, my bad. :-(
#11
I'm trying very hard to find something that adds the features discussed here. I'm willing to work with Drupal 5 or 6 as I have virtual machines set up to test both along with which modules are available for each that suit my organization's needs. Books are currently the best way to lay out information hierarchically that I can find and the absence of the ability to define editors based on role (or even user list) is frustrating.
#12