Issue status update for http://drupal.org/node/20890 Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: clydefrog Updated by: clydefrog Status: patch Attachment: http://drupal.org/files/issues/access_child_page_1.patch (3.71 KB) I finally have some free time, so here's an updated patch to sync with HEAD. clydefrog Previous comments: ------------------------------------------------------------------------ April 19, 2005 - 20:52 : clydefrog Attachment: http://drupal.org/files/issues/access_child_page.patch (3.26 KB) 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? ------------------------------------------------------------------------ April 20, 2005 - 05:45 : menesis 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. ------------------------------------------------------------------------ April 20, 2005 - 07:45 : clydefrog 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. ------------------------------------------------------------------------ April 26, 2005 - 17:42 : clydefrog Attachment: http://drupal.org/files/issues/access_child_page_0.patch (3.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.