Quantcast

Re: Quick (hopefully) User Permissions question

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Quick (hopefully) User Permissions question

Adam Franco
Administrator
Hi Dan, all,

I have solved this issue by adding a second checkbox to the MM permissions form to "Copy these permissions to all nodes on this page". If this option is checked, the permissions will be copied to all nodes on this page that a users has permission to change.

If the "Copy these permissions to all sub-pages of this page" is checked as well, the permissions will be copied to the nodes on all sub-pages as well (respecting access controls).

This change is implemented as an addition to the mm_ui_edit_cat form and an additional option to mm_content_add_replace_cat, "propagate_node_perms".

Excerpt from the attached patch:
+      // Copy the permissions onto nodes attached to the category/page if requested.
+      if ($parameters['propagate_node_perms']) {
+        foreach (mm_content_nodes_using_tids($t) as $nid) {
+          $node = node_load($nid);
+          if ($node && node_access('update', $node)) {
+            $node->users_w = array_flip($parameters['perms']['w']['users']);
+            $node->groups_w = array_flip($parameters['perms']['w']['groups']);
+            $node->others_w = (strpos($parameters['dflt_mode'], 'w') !== FALSE);
+         
+            mm_ui_set_node_perms($node);
+            watchdog('mm', 'Updated %name (%nid) node permissions.', array('%name' => $node->title, '%nid' => $nid));
+          }
+        }
+      }

Note that I am only setting write permission on the nodes. I am a little unclear about the relationship between page read permission and node read permission. If settings for read permission are just ignored and the page read permission is used, then this patch should be sufficient as-is. If not, I can add settings for node read permission as well and re-roll the patch.

I've tested the following situations and permission-writing seems to work as desired:
  • User has full permissions on a page, but not on sub-pages or any nodes:
    • User cannot grant themselves or others access to any nodes or sub-pages.
    • User can just grant others access to the page itself.
  • User has full permissions on a page and its nodes, but not on sub-pages or nodes on sub-pages:
    • User cannot grant themselves or others access to any sub-pages or nodes on sub-pages
    • User can grant others access to the page itself and the nodes on that page.
  • User has full permissions on a page and some of its nodes, but not on sub-pages or nodes on sub-pages:
    • User cannot grant themselves or others access to any sub-pages or nodes on sub-pages.
      User cannot grant themselves or others access to nodes on the page where they do not have full access.
    • User can grant others access to the page itself and the nodes on that page where the user has full access.
  • User has full permissions on a page and sub-pages, but not on every node on sub-pages:
    • Users cannot grant themselves or others access to nodes where they do not already have access.
    • Users can grant others access to the page and sub-pages, as well as all nodes where they do have full access.
Please let me know if I need to add read-permission setting, if I am missing something something else, or if I got some of the concepts wrong. I'm sure there are other ways of implementing this sort of feature, but this way seemed like it would fit in well with the permission-setting work-flow that users see and not drastically change any paradigms.

Thanks,
Adam

On Tue, Aug 4, 2009 at 1:02 PM, Dan Wilga <[hidden email]> wrote:
At 9:27 AM -0400 8/4/09, McBride, Ian wrote:
Interesting. I see how this separation works well when using groups to manage permissions and now wish I'd been able to be more proactive about setting that up when building out the site for our affiliate institution MIIS. The situation they're now in is that their "web super users" team has set up a bunch of content and they want to turn over management of that content to the users ultimately responsible for it. Naturally, they haven't yet populated those users into the page permissions settings, so none of them are included in the node editing settings either. It seems like they will need to go through and add the correct content editors for each content node now so that the editors will be able to update the content that's already in place.

We've found that the best practice to use when temporary people are creating content that will eventually be turned over to others is to create a group and apply that group at the top level, as the very first step. Then, any new subpages and content created on those pages gets the same group. Turning the stuff over to the final users is as simple as editing the group. Using groups is also much more space-efficient than using individual users.

I think the only way to solve your immediate problem would be to write a script which uses an mm_content_get_tree() iterator which then calls mm_content_nodes_using_tids() to determine the affected nodes, and mm_ui_set_node_perms() to save the permissions changes (along with a direct update to the uid field in the node table for the owner).

To do this, you'll need to know the mmtid of the starting page, the mmtids (gids) of the groups, and the uid of the owner to apply to the nodes.

--
Dan Wilga                                 [hidden email]
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: 413-542-2175
Amherst, MA  01002

---
You are currently subscribed to monster_menus as: [hidden email].
To unsubscribe click here: http://lists.middlebury.edu/u?id=685438.780c6126d238396bdd2f98c1d84c15c7&n=T&l=monster_menus&o=446597
or send a blank email to [hidden email]

---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=453343

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]


Cascade_MM_Perms.patch (4K) Download Attachment
MM Cascade Perms.png (136K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Quick (hopefully) User Permissions question

Adam Franco
Administrator
Attached is an updated version of this patch that adds a note about node-permission updates to the page-updated log message rather than flooding the logs with messages for each node updated.

- Adam

On Fri, Aug 21, 2009 at 11:57 AM, Adam Franco <[hidden email]> wrote:
Hi Dan, all,

I have solved this issue by adding a second checkbox to the MM permissions form to "Copy these permissions to all nodes on this page". If this option is checked, the permissions will be copied to all nodes on this page that a users has permission to change.

If the "Copy these permissions to all sub-pages of this page" is checked as well, the permissions will be copied to the nodes on all sub-pages as well (respecting access controls).

This change is implemented as an addition to the mm_ui_edit_cat form and an additional option to mm_content_add_replace_cat, "propagate_node_perms".

Excerpt from the attached patch:
+      // Copy the permissions onto nodes attached to the category/page if requested.
+      if ($parameters['propagate_node_perms']) {
+        foreach (mm_content_nodes_using_tids($t) as $nid) {
+          $node = node_load($nid);
+          if ($node && node_access('update', $node)) {
+            $node->users_w = array_flip($parameters['perms']['w']['users']);
+            $node->groups_w = array_flip($parameters['perms']['w']['groups']);
+            $node->others_w = (strpos($parameters['dflt_mode'], 'w') !== FALSE);
+         
+            mm_ui_set_node_perms($node);
+            watchdog('mm', 'Updated %name (%nid) node permissions.', array('%name' => $node->title, '%nid' => $nid));
+          }
+        }
+      }

Note that I am only setting write permission on the nodes. I am a little unclear about the relationship between page read permission and node read permission. If settings for read permission are just ignored and the page read permission is used, then this patch should be sufficient as-is. If not, I can add settings for node read permission as well and re-roll the patch.

I've tested the following situations and permission-writing seems to work as desired:
  • User has full permissions on a page, but not on sub-pages or any nodes:
    • User cannot grant themselves or others access to any nodes or sub-pages.
    • User can just grant others access to the page itself.
  • User has full permissions on a page and its nodes, but not on sub-pages or nodes on sub-pages:
    • User cannot grant themselves or others access to any sub-pages or nodes on sub-pages
    • User can grant others access to the page itself and the nodes on that page.
  • User has full permissions on a page and some of its nodes, but not on sub-pages or nodes on sub-pages:
    • User cannot grant themselves or others access to any sub-pages or nodes on sub-pages.
      User cannot grant themselves or others access to nodes on the page where they do not have full access.
    • User can grant others access to the page itself and the nodes on that page where the user has full access.
  • User has full permissions on a page and sub-pages, but not on every node on sub-pages:
    • Users cannot grant themselves or others access to nodes where they do not already have access.
    • Users can grant others access to the page and sub-pages, as well as all nodes where they do have full access.
Please let me know if I need to add read-permission setting, if I am missing something something else, or if I got some of the concepts wrong. I'm sure there are other ways of implementing this sort of feature, but this way seemed like it would fit in well with the permission-setting work-flow that users see and not drastically change any paradigms.

Thanks,
Adam


On Tue, Aug 4, 2009 at 1:02 PM, Dan Wilga <[hidden email]> wrote:
At 9:27 AM -0400 8/4/09, McBride, Ian wrote:
Interesting. I see how this separation works well when using groups to manage permissions and now wish I'd been able to be more proactive about setting that up when building out the site for our affiliate institution MIIS. The situation they're now in is that their "web super users" team has set up a bunch of content and they want to turn over management of that content to the users ultimately responsible for it. Naturally, they haven't yet populated those users into the page permissions settings, so none of them are included in the node editing settings either. It seems like they will need to go through and add the correct content editors for each content node now so that the editors will be able to update the content that's already in place.

We've found that the best practice to use when temporary people are creating content that will eventually be turned over to others is to create a group and apply that group at the top level, as the very first step. Then, any new subpages and content created on those pages gets the same group. Turning the stuff over to the final users is as simple as editing the group. Using groups is also much more space-efficient than using individual users.

I think the only way to solve your immediate problem would be to write a script which uses an mm_content_get_tree() iterator which then calls mm_content_nodes_using_tids() to determine the affected nodes, and mm_ui_set_node_perms() to save the permissions changes (along with a direct update to the uid field in the node table for the owner).

To do this, you'll need to know the mmtid of the starting page, the mmtids (gids) of the groups, and the uid of the owner to apply to the nodes.

--
Dan Wilga                                 [hidden email]
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: 413-542-2175
Amherst, MA  01002

---
You are currently subscribed to monster_menus as: [hidden email].
To unsubscribe click here: http://lists.middlebury.edu/u?id=685438.780c6126d238396bdd2f98c1d84c15c7&n=T&l=monster_menus&o=446597
or send a blank email to [hidden email]


---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=453385

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]


Cascade_MM_Perms-1.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Quick (hopefully) User Permissions question

Dan Wilga-2
In reply to this post by Adam Franco
Thanks for sending this, Adam.

I'm going to have to think about the best way to apply this to our
trunk, since it's very likely that our users are not going to want to
add yet another option to the page permissions. I think it will
probably have to be a config setting, as much as I hate to do it that
way.

Eventually I think there are going to be lots of things like this,
since we have many idiosyncratic features that others probably don't
want or need on their sites.
--
Dan Wilga                                 [hidden email]
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: 413-542-2175
Amherst, MA  01002

---
You are currently subscribed to monster_menus as: [hidden email].
To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=453409
or send a blank email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Quick (hopefully) User Permissions question

Adam Franco
Administrator
In reply to this post by Adam Franco
A config setting would be fine with us. Is there an existing MM configuration form that I should add an option to, or is this something you'd rather work out?

Also, other than adding clutter to the Permissions UI, are there other cases you can think of where having this option would be problematic? It doesn't seem like this option would cause us problems, but I wouldn't want to paint anyone into a corner if this option were enabled.

Thanks,
Adam

On Fri, Aug 21, 2009 at 4:27 PM, Dan Wilga <[hidden email]> wrote:
Thanks for sending this, Adam.

I'm going to have to think about the best way to apply this to our trunk, since it's very likely that our users are not going to want to add yet another option to the page permissions. I think it will probably have to be a config setting, as much as I hate to do it that way.

Eventually I think there are going to be lots of things like this, since we have many idiosyncratic features that others probably don't want or need on their sites.

--
Dan Wilga                                 [hidden email]
Web System Administrator/Programmer             http://www.amherst.edu
Amherst College                                      Tel: 413-542-2175
Amherst, MA  01002

---
You are currently subscribed to monster_menus as: [hidden email].
To unsubscribe click here: http://lists.middlebury.edu/u?id=685438.780c6126d238396bdd2f98c1d84c15c7&n=T&l=monster_menus&o=453409
or send a blank email to [hidden email]

---

You are currently subscribed to monster_menus as: [hidden email].

To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=453412

(It may be necessary to cut and paste the above URL if the line is broken)

or send a blank email to [hidden email]

Loading...