This patch makes it possible to restrict which nodes can be used as parents when editing child book pages. Here's a quick summary of the changes:

  • Add grant_create_child column to node_access page.
  • Set grant_create_child to 1 in the default nid = 0 row.
  • Pass array('op' => 'create_child') to db_rewrite_sql() in book_toc().
  • Modify node_db_rewrite_sql() so that the "$op" argument is used in _node_access_where_sql()
  • Generalize node_access_view_all_nodes() to node_access_all_nodes($op)

I'm not sure I've covered all the bases. In particular, the "add child page" link still appears on all book pages. Also, there is nothing stopping a clueful user from passing an arbitrary parent nid when submitting. But shouldn't those be the responsibility of the particular node_access module?

Thanks for considering this patch.

An aside: The attached patch was made with "diff -ru". Is it acceptable to use "cvs diff -u" as well?

CommentFileSizeAuthor
#4 access_child_page_1.patch3.71 KBezheidtmann
#3 access_child_page_0.patch3.71 KBezheidtmann
access_child_page.patch3.26 KBezheidtmann

Comments

menesis’s picture

menesis commented

Child page is a concept used only in book module, so it should be implemented there, and in different way. If you used a different node access module than node_privacy_byrole, your changes would make no sense at all... For example, using taxonomy_access, you could restrict some user roles from adding child pages to any book page in some categories...

If your intention is to mark some book pages as "final", I would modify only book module. Add another column to book table, e.g. leaf, which defaults to 0. Add a checkbox to book_form which lets users with "administer nodes" permission to mark this page as leaf. Modify book_toc to select only nodes which can be parents, i.e. " AND NOT b.leaf ". Check if book page can have children before displaying "Add child page" link. And so on.

ezheidtmann’s picture

ezheidtmann commented

I think restricting some users from adding child pages to any book page in some categories is a perfectly reasonable thing to do. It's not what I plan to use this functionality for, but I don't see any problem with it.

My intention is to allow a user access to add child pages to his or her book, but to disallow all other users. This is not difficult to do by modifying book.module, but I hoped that by making the changes in this patch I would allow other contrib module authors the ability to restrict which nodes can be parents *without* patching core modules.

It is true that the child-parent relationship is unique to book.module. However, except for the change to the node_access table, all changes outside book.module simply make the node_access system more general. Before this patch, AFAICT, node access modules could not restrict update or delete operations.

ezheidtmann’s picture

ezheidtmann commented
StatusFileSize
new access_child_page_0.patch3.71 KB

The updated patch syncs with HEAD and updates the inline documentation.

I just realized that "Clipper" and "Node Relativity" could also be used with this patch because they have parent-child relationships, so that makes this patch, IMO, more suitable for inclusion. Thanks for your time.

ezheidtmann’s picture

ezheidtmann commented
StatusFileSize
new access_child_page_1.patch3.71 KB

I finally have some free time, so here's an updated patch to sync with HEAD.

moshe weitzman’s picture

moshe weitzman commented

i also think this is too much of a special case for the ndoe access ssytem. I suggest adding a checbox using nodeapi(form post) if selected parent is valid from within nodeapi(validate). these can be done in a new module, without patching book or node or anything else.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Needs work
Jaza’s picture

Jaza commented
Version: x.y.z » 6.x-dev

Moving to 6.x-dev queue. I also agree that this doesn't belong in the node_access table, as it's specific to hierarchical nodes. I have my doubts about this really needing to be in core at all.

catch’s picture

catch
he/him
Primary language English
commented
Version: 6.x-dev » 7.x-dev
Status: Needs work » Active

Setting back to active due to book module rewrite.

moshe weitzman’s picture

moshe weitzman commented

There are a lot of modules that doe hierarchies of nodes so I change my mind on this one. I now agree that the node access system could use this column. For another example of hierarchical content, see http://groups.drupal.org/node/10231

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented
Component: node system » book.module

Bump. Until we have a dedicated hierarchy API in core, moving to book.module

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.