overhaul of permissions issues in node relativity

As far as I know for User B to be able to attach child nodes to User A's parent node User B needs the edit not edit own permission for the parent node's content type.

Using your auction example Users A and B need to be in a role that has the

- create auction content
- edit auction content
- create bid content
- edit bid content

permissions set for it.

The downside is that User B would also be able to edit the parent node, see issue at http://drupal.org/node/92552.

omar's patch : http://drupal.org/node/92552 is very simple and changes default child-bearing rules to promiscuous.

All the patch does is change one line to remove the node_access check (= node-edit permission) from the add child function. It works well and IMO is preferable default behaviour. But it is nice to know you could change it back for blogbooks if you ever wanted to ... :)

<?php
--- relativity.module.old    2006-12-12 19:51:56.000000000 +0200
+++ relativity.module    2006-12-12 19:52:02.000000000 +0200
@@ -1402,7 +1402,7 @@

       // only offer to let user create new child if user has 'create' access
       // and common child relationship isn't required
-      if ($may_create && node_access('update', $parent)) {
+            if ($may_create) {
         $output .= l(t('create new %type', array('%type'=>$type_name)), "node/add/$type/parent/$parent_nid");
       }
  ?>

Until a better overhaul of permissions issues in node relativity, I would rather keep the existing behavior as default, since changing it might affect a lot of people. Please remember that the current one line change is in the *theme* function, which means you can suit to y6our own needs as much as you want. Theme functions are meant to be changed by users.

@ darius - default behaviour - fair enough.
@ darius - your 'theme_' hint - you mean hacking a function phptemplate_relativity_links into your node-#parent_type.tpl.php to liberate #parent_type nodes ? hmm... crude but effective ;)

Hows about including 3 more select options foreach node-type relationship :?

admin/settings/relativity/advanced ->
Options for #parenttype (#parenttype) nodes:

• Allowed Operations for #childtype Children :
  • 'Create new #childtype':
    1. only #parenttype node author. (default)
    2. any user with 'create #childtype content' permission.
  • 'Attach #childtype':
    1. only #parenttype node author. (default)
    2. any user with 'create #childtype content' permission. (?)
    3. any user with 'edit #parenttype content' permission.
  • 'Detach #childtype':
    1. only #parenttype node author. (default)
    2. any user with 'edit #parenttype content' permission. (I am right in thinking this is not currently supported ?)

Does that sound too complicated? (In know, I know ... patches are always welcome ... ;) But does the logic allow all the UI permissions-flexibility we could possibly need ?

another problem with current permission check system:

If a node may only have one parent and then a clumsy user manages to 'Remove' the node from it's parent; the poor little orphan is lost! The only way I can figure to re-attach it is temporarily set the orphan's node type to [parent any], 'Attach existing ...' from the parent node, and then reset. This is a nuisance for site Admin.

One solution to #7 would be to
hide 'Remove' links if the (child) node's parent ordinality is set to "one"
... so that the only way to 'Remove' that child is to delete the node. Does that make sense ?