[drupal-devel] [feature] Add create_child grant type in node_access system

[clydefrog]

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_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.




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.