[drupal-devel] [bug] Users with 'maintain books' or 'edit own book pages' permission cannot delete book pages

Bèr Kessels drupal-devel at drupal.org
Mon Aug 8 21:08:04 UTC 2005

Issue status update for 
Post a follow up: 

 Project:      Drupal
 Version:      cvs
 Component:    book.module
 Category:     bug reports
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  clydefrog
 Updated by:   Bèr Kessels
 Status:       patch (code needs review)

puregrin. I think you are gettnig OT here, Thought it is a very valid
(and problematic) issue, It really belongs in a new thread.

Bèr Kessels

Previous comments:

Fri, 29 Apr 2005 04:32:19 +0000 : clydefrog

Attachment: http://drupal.org/files/issues/delete_own_book_pages.patch (626 bytes)

AFAICT, only 'administer nodes' permission allows deletion of book

This patch allows users with 'maintain books' or 'edit own book pages'
permission to delete book pages. The logic doesn't check if the node
has updates pending. Should it?


Fri, 29 Apr 2005 14:10:22 +0000 : clydefrog

It's a patch, duh.


Fri, 29 Apr 2005 14:21:27 +0000 : rivena

If maintain books is a permission that overlaps other permissions, it
should say so.  For example, /maintain books (create, edit, and delete
all book pages)/.  

While I agree that someone who has been given maintainer status should
be able to delete pages, I wonder if 'delete own pages' should be made
into a seperate permission.  I could see a situation where I would not
want someone to be able to delete their own pages.

Do these permissions affect things that are not book pages but have
been put into books?

It's /Golden Week/!


Sat, 30 Apr 2005 03:43:17 +0000 : clydefrog

I think it's clear that "maintain books" implies the ability to edit and
delete book pages.

No other node module provides a "delete own " permission, so it would
be inconsistent for book.module to provide it. Can you provide some
examples to justify the inconsistency?

These permissions do not affect nodes which aren't book pages but are
in a book. Those nodes are controlled by their respective type-specific
permissions, but only users with "maintain books" permission can add or
remove those nodes from books. I believe this is the correct behavior.


Sat, 30 Apr 2005 11:03:47 +0000 : rivena

Hmm...  But, you just said that until this patch, it *didn't* include
the delete pages permission.  Right?  So, now you are changing it's
behavior, but leaving the wording the same.  How will people know?  Or
does it not matter, because you presume they didn't really know it
didn't include delete in the first place?

I don't know that I can defend my idea of having a seperate delete own
pages permission against a standard of consistency.  If all the other
edit own permissions include the delete pages permission, then I have
no quibbles.  :)

Except it would be more userfriendly if I knew what the permissions
meant before I granted them to someone, without having to look at the
code.  But I do realize that is completely out of the scope of the
patch.  :)

Where do all these little changes *go*, anyway?  The changelog just
says things like...  refractored the search module.



Sat, 30 Apr 2005 16:04:14 +0000 : clydefrog

I believe that "maintain books" permission implies the ability to delete
book pages, so this patch fixes that bug.

Other node modules include deletion in the "edit own" permission. For
example, page.module:

  if ($op == 'update' || $op == 'delete') {
    if (user_access('edit own pages') && ($user->uid ==
$node->uid)) {
      return TRUE;

I agree that it would be better if permissions were clearer about what
they implied. There was a discussion started by killes [1] a while ago:

"One problem with Drupal is the way it handles user permissions. The
permissions are attached to the user object but nobody really knows
they do. To find out what a particular permission allows you to do, you
often need to have a look at the code.

I don't know if it ever lead to any code.

I think the changelog is meant to list the changes since the previous
version without too much technical detail. If you want to see every
last change, take a look at the cvs messages [2].
[1] http://lists.drupal.org/archives/drupal-devel/2005-04/msg00704.html
[2] http://drupal.org/project/cvs/3060


Mon, 23 May 2005 17:33:18 +0000 : rivena

I've been looking at the book module permissions recently, and did a bit
of testing.  I wanted to know what was the minimum permissions needed to
create a new book.  I assumed based on this discussion, and a similar
discussion on the drupal support list that this was 'maintain books'
and 'administer nodes'.  I ran into a problem, then added 'access
nodes' to this.  

So now my user has no other permissions other than 'maintain books',
'administer nodes' and 'access nodes'.  You'd think this is more than
sufficient to do something simple like create a new book, but in fact,
with just these permissions, you do not have access to create a book
page.  You can edit other pages, and move them into a new book.

Once you have create pages permission, you appear to finally have all
the permissions needed, edit own pages is not needed.

So, since, the point of this patch was that not having delete
permission was odd, might I suggest adding create permission to
maintain books?  ;p



Mon, 08 Aug 2005 10:37:49 +0000 : Bèr Kessels

I would say this is a "by design".
Maybe we need to rename the two book permissions into:
"create books" and "edit own book pages".
None of the other nodes can be deleted by the roles with "edit own Foo"
permissions, nor should the books.


Mon, 08 Aug 2005 16:59:30 +0000 : clydefrog

Thanks for your review, Ber.

story.module [3] allows users with "edit own stories" permission to
delete stories.

  if ($op == 'update' || $op == 'delete') {
    if (user_access('edit own stories') && ($user->uid ==
$node->uid)) {
      return TRUE;

Therefore it is not inconsistent for the same behavior to apply to book

If "maintain books" really means "create books", then the name should
be changed and existing code in book.module needs to be updated.
However, I think "maintain books" should allow more than just that. In
my situation, I want to be able to give someone the permissions to
create books and to create, edit, and delete all book pages. With my
patch, "maintain books" and "create book pages" does that.


Mon, 08 Aug 2005 19:16:35 +0000 : Bèr Kessels

What i see from story, that is specific to story.module too.

We should really settle for a consistent behaviour for *all* nodes, one
that is "enforced" from node.module. These things should really not be
decided per node-type and per-module. Thats a recipe for a mess.


Mon, 08 Aug 2005 19:25:27 +0000 : Eric Scouten

I agree that the current system is a mess.

I disagree that there should be one consistent policy enforced by
node.module. Sites may have quite legitimate reasons to have different
policies for different node types.


Mon, 08 Aug 2005 20:35:59 +0000 : Bèr Kessels

What i was aiming at is to let node module take care of the following:
* edit $node_type
* administer $node_type
* delete $node_type (but would that not better be in 'administer';:
users who can administer can delete)
* create $node_type

That way the modules need not cre about this. ut they /can/ take care
of it, if they wish, and add more rules and permissions.


Mon, 08 Aug 2005 20:36:32 +0000 : Bèr Kessels

oh, and -forgot- :
* view $node_type


Mon, 08 Aug 2005 20:49:31 +0000 : Eric Scouten

Thanks for the clarification, Bèr. I was afraid that you meant that
there would be a single policy applied to *all* node types, not a
policy *per* node type.

Now I think we're in complete agreement on this subject.


Mon, 08 Aug 2005 20:51:13 +0000 : puregin

I think it's important to keep a clean separation between content and
structure (e.g.,
what's inside of the node, versus how the node is associated with other

I think that there will likely be other explicit structures in Drupal
over time, so these concerns affect more than just book module.

Deleting a node from a book is potentially a problem, since this
operation affects the structure
of a book.  

We also need to think about other interactions with structure - for
example, what happens
if someone unpublished a node in a book?  Should all children also be
unpublished?  Should the node contents be hidden, while children remain
available in navigation?

More information about the drupal-devel mailing list