Quantcast

views and mm permissions

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

views and mm permissions

grahamtk
This post has NOT been accepted by the mailing list yet.
Hi!
We have a view on users profile pages with nodes that the user has authored.

The problem now is that this view now shows all nodes authored, not taking monster menus permissions into account.
Is this configurable? Or would it have to be programmed?
Any help much appreciated!

Øyvind
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: views and mm permissions

Dan Wilga-2
You have hit upon a limitation of the complex way in which MM calculates
permissions: there is no way to integrate this calculation directly in a
view result set as an "only show me the nodes the user can edit" filter.

There are various ways around this, though. One way is to put all of the
nodes on a single MM-protected page. Then, add a "Nodes on MM page"
contextual filter to your view which receives the mmtid of the page as a
parameter. To avoid having to call the view in PHP code, you can use
something like the viewfield module
(https://www.drupal.org/project/viewfield) to render the view with the
correct mmtid as a parameter.

On 3/11/15 4:24 AM, grahamtk wrote:

> Hi!
> We have a view on users profile pages with nodes that the user has authored.
>
> The problem now is that this view now shows all nodes authored, not taking
> monster menus permissions into account.
> Is this configurable? Or would it have to be programmed?
> Any help much appreciated!
>
> Øyvind
>


---
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=713013
or send a blank email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: views and mm permissions

grahamtk
In reply to this post by grahamtk
I only want nodes that is viewable by anonymous visitors . Intranet content is now visible to external visitors.

Mvh.
Øyvind Graham

Den 11. mar. 2015 kl. 13.55 skrev Dan Wilga <[hidden email]>:

You have hit upon a limitation of the complex way in which MM calculates permissions: there is no way to integrate this calculation directly in a view result set as an "only show me the nodes the user can edit" filter.

There are various ways around this, though. One way is to put all of the nodes on a single MM-protected page. Then, add a "Nodes on MM page" contextual filter to your view which receives the mmtid of the page as a parameter. To avoid having to call the view in PHP code, you can use something like the viewfield module (https://www.drupal.org/project/viewfield) to render the view with the correct mmtid as a parameter.

> On 3/11/15 4:24 AM, grahamtk wrote:
> Hi!
> We have a view on users profile pages with nodes that the user has authored.
>
> The problem now is that this view now shows all nodes authored, not taking
> monster menus permissions into account.
> Is this configurable? Or would it have to be programmed?
> Any help much appreciated!
>
> Øyvind
>


---
You are currently subscribed to monster_menus as: [hidden email].
To unsubscribe click here: http://lists.middlebury.edu/u?id=1410382.5af74b4693b81b84495f479a03f0e1ec&n=T&l=monster_menus&o=713013
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=713015
or send a blank email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: views and mm permissions

Dan Wilga-2
In reply to this post by grahamtk
The only way I can think of to do this would be to add some PHP code in
a views pre_render hook that calls mm_content_user_can_node() for each
result and removes the ones that the user can't view.

On 3/11/15 9:43 AM, Øyvind Graham wrote:

> I only want nodes that is viewable by anonymous visitors . Intranet content is now visible to external visitors.
>
> Mvh.
> Øyvind Graham
>
> Den 11. mar. 2015 kl. 13.55 skrev Dan Wilga <[hidden email]>:
>
> You have hit upon a limitation of the complex way in which MM calculates permissions: there is no way to integrate this calculation directly in a view result set as an "only show me the nodes the user can edit" filter.
>
> There are various ways around this, though. One way is to put all of the nodes on a single MM-protected page. Then, add a "Nodes on MM page" contextual filter to your view which receives the mmtid of the page as a parameter. To avoid having to call the view in PHP code, you can use something like the viewfield module (https://www.drupal.org/project/viewfield) to render the view with the correct mmtid as a parameter.
>
>> On 3/11/15 4:24 AM, grahamtk wrote:
>> Hi!
>> We have a view on users profile pages with nodes that the user has authored.
>>
>> The problem now is that this view now shows all nodes authored, not taking
>> monster menus permissions into account.
>> Is this configurable? Or would it have to be programmed?
>> Any help much appreciated!
>>
>> Øyvind
>>


---
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=713016
or send a blank email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: views and mm permissions

Adam Franco
Administrator
In reply to this post by grahamtk
Hi Øyvind,

As Dan mentioned, this isn't easy to do with views. I tried to do the same thing in the past as a views filter, specifically, the monster_menus_views_handler_filter_readable mentioned in this (closed) issue and the patches on that issue. Here's the part of that patch related to the filter:
diff --git a/sites/all/modules/monster_menus/modules/mm_views/mm_views.module b/sites/all/modules/monster_menus/modules/mm_views/mm_views.module
index 1789b15..12ede8a --- a/sites/all/modules/monster_menus/modules/mm_views/mm_views.module +++ b/sites/all/modules/monster_menus/modules/mm_views/mm_views.module
@@ -144,6 +289,9 @@ function mm_views_views_handlers() { 'parent' => 'views_handler_field_node', ), // filter handlers + 'mm_views_handler_filter_readable' => array( + 'parent' => 'views_handler_filter', + ),

diff --git a/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc b/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc new file mode 100644 index 0000000..da3b616 --- /dev/null +++ b/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc @@ -0,0 +1,34 @@ +<?php +/** + * @file + * Views interface for filtering by Monster Menus view permission + */ + +class mm_views_handler_filter_readable extends views_handler_filter { + function admin_summary() { } + function operator_form() { } + function can_expose() { + return FALSE; + } + + function query() { + global $user; + + // Don't filter for admins + if (user_access('administer all menus')) + return; + + // Build the Where clause + $where = "\n {mm_tree}.default_mode REGEXP('r')"; + if ($user->uid) { + $where .= "\n OR ( + {mm_tree_access}.mode IN ('r', 'w', 'u') + AND {mm_tree_access}.gid IN (SELECT gid FROM mm_group WHERE uid = ".$user->uid.") + )"; + } + $where .= "\n"; + + $this->ensure_my_table(); + $this->query->add_where($this->options['group'], $where); + } +}
As Dan clarified in his comments on that issue, this 'readable' filter doesn't calculate permissions correctly, because it only looked at the parent page's visibility and not the visibility of the full parent-hierarchy. Were read-access to be removed from a page higher in the hierarchy then a node should not be visible even if its direct parent page has read-access granted.

I still have a use for this kind of filter and am using the one above in a single-purpose site that doesn't allow users to change page permissions, making its limitations acceptable. I'd love to see an accurate views filter right in the views UI that would work in all cases, even if that means doing extra calls to mm_content_user_can_node() before returning results.

Let us know what you come up with!

Adam

--

Adam Franco
Senior Software Developer
Information Technology Services
Middlebury College
Middlebury, VT 05753
[hidden email]
802.443.2244

On Wed, Mar 11, 2015 at 10:21 AM, Dan Wilga <[hidden email]> wrote:
The only way I can think of to do this would be to add some PHP code in
a views pre_render hook that calls mm_content_user_can_node() for each
result and removes the ones that the user can't view.

On 3/11/15 9:43 AM, Øyvind Graham wrote:
> I only want nodes that is viewable by anonymous visitors . Intranet content is now visible to external visitors.
>
> Mvh.
> Øyvind Graham
>
> Den 11. mar. 2015 kl. 13.55 skrev Dan Wilga <[hidden email]>:
>
> You have hit upon a limitation of the complex way in which MM calculates permissions: there is no way to integrate this calculation directly in a view result set as an "only show me the nodes the user can edit" filter.
>
> There are various ways around this, though. One way is to put all of the nodes on a single MM-protected page. Then, add a "Nodes on MM page" contextual filter to your view which receives the mmtid of the page as a parameter. To avoid having to call the view in PHP code, you can use something like the viewfield module (https://www.drupal.org/project/viewfield) to render the view with the correct mmtid as a parameter.
>
>> On 3/11/15 4:24 AM, grahamtk wrote:
>> Hi!
>> We have a view on users profile pages with nodes that the user has authored.
>>
>> The problem now is that this view now shows all nodes authored, not taking
>> monster menus permissions into account.
>> Is this configurable? Or would it have to be programmed?
>> Any help much appreciated!
>>
>> Øyvind
>>


---
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=713016
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=713071

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

or send a blank email to [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: views and mm permissions

grahamtk
This post has NOT been accepted by the mailing list yet.
Given that visibility is a product of all pages in ancestry of a page, this sounds like a problem I have met before where we had different group memberships amounting to different sets of permissions. We solved it with a bitmask for the permissions for each group where each bit granted a given action. To find the sum of permissions this was done with a bitwise And (&) operator. Ofcourse here we have a sum of group permissions and page path ancestry so added level of complexity. 

Given a permission mask like this:
Read   _____________
Write   __________     |
Add     ______      |     |
Delete  ___     |     |     |
                1    1    1    1
Where 0 is deny and 1 is grant access 
$read_perms = 0001


The path permissions would be a bitwise and of all rows, meaning the first deny would deny access.  

But for each page there should be a bitwise or so the widest access a user posess is given precedence over more restricted access. 

So the access can be done like:
|   bitwise or
&  bitwise and

Front page;
Users group a             0 0 0 1
|
Users group b             0 0 0 1
=                                                0001  &

Subpage a;                
Users group a            0 0 0 1
Users group b            0 0 0 1
=                                                0001  &

Intrawebz frontpage.
Users group a             0 0 0 0
|
Users group b             0 0 0 0
=                                               0000  &
Articles page        
Users group a              0 0 1 1
|
Users group b              0 0 0 1
=                                               0011   &

0001
&
0001
&
0000
&
0011
=
$users_perms= 0000 

Access test: 
$users_perms
&
$read_perms
= no access. 

No idea if permissions in mm is implemented with bitmasks, but it would help my understamding if it was. 

Could i get a short summary of how permissions are stored and calculated in mm? 

Mvh. 
Øyvind Graham

Den 12. mar. 2015 kl. 16.23 skrev Adam Franco [via Monster Menus] <[hidden email]>:

Hi Øyvind,

As Dan mentioned, this isn't easy to do with views. I tried to do the same thing in the past as a views filter, specifically, the monster_menus_views_handler_filter_readable mentioned in this (closed) issue and the patches on that issue. Here's the part of that patch related to the filter:
diff --git a/sites/all/modules/monster_menus/modules/mm_views/mm_views.module b/sites/all/modules/monster_menus/modules/mm_views/mm_views.module
index 1789b15..12ede8a --- a/sites/all/modules/monster_menus/modules/mm_views/mm_views.module +++ b/sites/all/modules/monster_menus/modules/mm_views/mm_views.module
@@ -144,6 +289,9 @@ function mm_views_views_handlers() { 'parent' => 'views_handler_field_node', ), // filter handlers + 'mm_views_handler_filter_readable' => array( + 'parent' => 'views_handler_filter', + ),

diff --git a/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc b/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc new file mode 100644 index 0000000..da3b616 --- /dev/null +++ b/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc @@ -0,0 +1,34 @@ +<?php +/** + * @file + * Views interface for filtering by Monster Menus view permission + */ + +class mm_views_handler_filter_readable extends views_handler_filter { + function admin_summary() { } + function operator_form() { } + function can_expose() { + return FALSE; + } + + function query() { + global $user; + + // Don't filter for admins + if (user_access('administer all menus')) + return; + + // Build the Where clause + $where = "\n {mm_tree}.default_mode REGEXP('r')"; + if ($user->uid) { + $where .= "\n OR ( + {mm_tree_access}.mode IN ('r', 'w', 'u') + AND {mm_tree_access}.gid IN (SELECT gid FROM mm_group WHERE uid = ".$user->uid.") + )"; + } + $where .= "\n"; + + $this->ensure_my_table(); + $this->query->add_where($this->options['group'], $where); + } +}
As Dan clarified in his comments on that issue, this 'readable' filter doesn't calculate permissions correctly, because it only looked at the parent page's visibility and not the visibility of the full parent-hierarchy. Were read-access to be removed from a page higher in the hierarchy then a node should not be visible even if its direct parent page has read-access granted.

I still have a use for this kind of filter and am using the one above in a single-purpose site that doesn't allow users to change page permissions, making its limitations acceptable. I'd love to see an accurate views filter right in the views UI that would work in all cases, even if that means doing extra calls to mm_content_user_can_node() before returning results.

Let us know what you come up with!

Adam

--

Adam Franco
Senior Software Developer
Information Technology Services
Middlebury College
Middlebury, VT 05753
[hidden email]
802.443.2244

On Wed, Mar 11, 2015 at 10:21 AM, Dan Wilga <[hidden email]> wrote:
The only way I can think of to do this would be to add some PHP code in
a views pre_render hook that calls mm_content_user_can_node() for each
result and removes the ones that the user can't view.

On 3/11/15 9:43 AM, Øyvind Graham wrote:
> I only want nodes that is viewable by anonymous visitors . Intranet content is now visible to external visitors.
>
> Mvh.
> Øyvind Graham
>
> Den 11. mar. 2015 kl. 13.55 skrev Dan Wilga <[hidden email]>:
>
> You have hit upon a limitation of the complex way in which MM calculates permissions: there is no way to integrate this calculation directly in a view result set as an "only show me the nodes the user can edit" filter.
>
> There are various ways around this, though. One way is to put all of the nodes on a single MM-protected page. Then, add a "Nodes on MM page" contextual filter to your view which receives the mmtid of the page as a parameter. To avoid having to call the view in PHP code, you can use something like the viewfield module (https://www.drupal.org/project/viewfield) to render the view with the correct mmtid as a parameter.
>
>> On 3/11/15 4:24 AM, grahamtk wrote:
>> Hi!
>> We have a view on users profile pages with nodes that the user has authored.
>>
>> The problem now is that this view now shows all nodes authored, not taking
>> monster menus permissions into account.
>> Is this configurable? Or would it have to be programmed?
>> Any help much appreciated!
>>
>> Øyvind
>>


---
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=713016
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=713071

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

or send a blank email to [hidden email]




If you reply to this email, your message will be added to the discussion below:
http://monster-menus.2910260.n2.nabble.com/views-and-mm-permissions-tp7573064p7573069.html
To start a new topic under Monster Menus, email [hidden email]
To unsubscribe from Monster Menus, click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: views and mm permissions

grahamtk
In reply to this post by Adam Franco
Given that visibility is a product of all pages in ancestry of a page, this sounds like a problem I have met before where we had different group memberships amounting to different sets of permissions. We solved it with a bitmask for the permissions for each group where each bit granted a given action. To find the sum of permissions this was done with a bitwise And (&) operator. Ofcourse here we have a sum of group permissions and page path ancestry so added level of complexity. 

Given a permission mask like this:
Read   _____________
Write   __________     |
Add     ______      |     |
Delete  ___     |     |     |
                1    1    1    1
Where 0 is deny and 1 is grant access 
$read_perms = 0001


The path permissions would be a bitwise and of all rows, meaning the first deny would deny access.  

But for each page there should be a bitwise or so the widest access a user posess is given precedence over more restricted access. 

So the access can be done like:
|   bitwise or
&  bitwise and

Front page;
Users group a             0 0 0 1
|
Users group b             0 0 0 1
=                                                0001  &

Subpage a;                
Users group a            0 0 0 1
Users group b            0 0 0 1
=                                                0001  &

Intrawebz frontpage.
Users group a             0 0 0 0
|
Users group b             0 0 0 0
=                                               0000  &
Articles page        
Users group a              0 0 1 1
|
Users group b              0 0 0 1
=                                               0011   &

0001
&
0001
&
0000
&
0011
=
$users_perms= 0000 

Access test: 
$users_perms
&
$read_perms
= no access. 

No idea if permissions in mm is implemented with bitmasks, but it would help my understamding if it was. 

Could i get a short summary of how permissions are stored and calculated in mm? 

Mvh. 
Øyvind Graham

Den 12. mar. 2015 kl. 16.23 skrev Adam Franco [via Monster Menus] <[hidden email]>:

Hi Øyvind,

As Dan mentioned, this isn't easy to do with views. I tried to do the same thing in the past as a views filter, specifically, the monster_menus_views_handler_filter_readable mentioned in this (closed) issue and the patches on that issue. Here's the part of that patch related to the filter:
diff --git a/sites/all/modules/monster_menus/modules/mm_views/mm_views.module b/sites/all/modules/monster_menus/modules/mm_views/mm_views.module
index 1789b15..12ede8a --- a/sites/all/modules/monster_menus/modules/mm_views/mm_views.module +++ b/sites/all/modules/monster_menus/modules/mm_views/mm_views.module
@@ -144,6 +289,9 @@ function mm_views_views_handlers() { 'parent' => 'views_handler_field_node', ), // filter handlers + 'mm_views_handler_filter_readable' => array( + 'parent' => 'views_handler_filter', + ),

diff --git a/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc b/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc new file mode 100644 index 0000000..da3b616 --- /dev/null +++ b/sites/all/modules/monster_menus/modules/mm_views/mm_views_handler_filter_readable.inc @@ -0,0 +1,34 @@ +<?php +/** + * @file + * Views interface for filtering by Monster Menus view permission + */ + +class mm_views_handler_filter_readable extends views_handler_filter { + function admin_summary() { } + function operator_form() { } + function can_expose() { + return FALSE; + } + + function query() { + global $user; + + // Don't filter for admins + if (user_access('administer all menus')) + return; + + // Build the Where clause + $where = "\n {mm_tree}.default_mode REGEXP('r')"; + if ($user->uid) { + $where .= "\n OR ( + {mm_tree_access}.mode IN ('r', 'w', 'u') + AND {mm_tree_access}.gid IN (SELECT gid FROM mm_group WHERE uid = ".$user->uid.") + )"; + } + $where .= "\n"; + + $this->ensure_my_table(); + $this->query->add_where($this->options['group'], $where); + } +}
As Dan clarified in his comments on that issue, this 'readable' filter doesn't calculate permissions correctly, because it only looked at the parent page's visibility and not the visibility of the full parent-hierarchy. Were read-access to be removed from a page higher in the hierarchy then a node should not be visible even if its direct parent page has read-access granted.

I still have a use for this kind of filter and am using the one above in a single-purpose site that doesn't allow users to change page permissions, making its limitations acceptable. I'd love to see an accurate views filter right in the views UI that would work in all cases, even if that means doing extra calls to mm_content_user_can_node() before returning results.

Let us know what you come up with!

Adam

--

Adam Franco
Senior Software Developer
Information Technology Services
Middlebury College
Middlebury, VT 05753
[hidden email]
802.443.2244

On Wed, Mar 11, 2015 at 10:21 AM, Dan Wilga <[hidden email]> wrote:
The only way I can think of to do this would be to add some PHP code in
a views pre_render hook that calls mm_content_user_can_node() for each
result and removes the ones that the user can't view.

On 3/11/15 9:43 AM, Øyvind Graham wrote:
> I only want nodes that is viewable by anonymous visitors . Intranet content is now visible to external visitors.
>
> Mvh.
> Øyvind Graham
>
> Den 11. mar. 2015 kl. 13.55 skrev Dan Wilga <[hidden email]>:
>
> You have hit upon a limitation of the complex way in which MM calculates permissions: there is no way to integrate this calculation directly in a view result set as an "only show me the nodes the user can edit" filter.
>
> There are various ways around this, though. One way is to put all of the nodes on a single MM-protected page. Then, add a "Nodes on MM page" contextual filter to your view which receives the mmtid of the page as a parameter. To avoid having to call the view in PHP code, you can use something like the viewfield module (https://www.drupal.org/project/viewfield) to render the view with the correct mmtid as a parameter.
>
>> On 3/11/15 4:24 AM, grahamtk wrote:
>> Hi!
>> We have a view on users profile pages with nodes that the user has authored.
>>
>> The problem now is that this view now shows all nodes authored, not taking
>> monster menus permissions into account.
>> Is this configurable? Or would it have to be programmed?
>> Any help much appreciated!
>>
>> Øyvind
>>


---
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=713016
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=713071

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

or send a blank email to [hidden email]




If you reply to this email, your message will be added to the discussion below:
http://monster-menus.2910260.n2.nabble.com/views-and-mm-permissions-tp7573064p7573069.html
To start a new topic under Monster Menus, email [hidden email]
To unsubscribe from Monster Menus, click here.
NAML


View this message in context: Re: views and mm permissions
Sent from the Monster Menus mailing list archive at Nabble.com.

---

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=713081

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

or send a blank email to [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: views and mm permissions

Dan Wilga-2
In reply to this post by grahamtk
Hi there,

Permissions are currently stored in a combination of tables:

mm_tree_parents: For a given mmtid, stores a list of its parent pages
mm_tree_access: For a given mmtid, contains a list of groups and the mode with which they are applied (read/write/etc.) to the page
mm_group: Membership of each group, including "individual users" which are really just single-use groups
mm_virtual_group: Membership of virtual groups
mm_node_write: Permissions on the node, itself

The problem with representing this sort of information using a bitmask is that MySQL is a relational database, and is not really geared toward doing that. Furthermore, there is a lot more logic to deciding if a given user can access a given node. You have to consider all of these things:

- permission at parent levels
- permissions of ALL pages on which the node appears
- permission of the node itself
- whether the user is an administrator or has other "super user" privs

And, finally, you have to do it all in a single SQL query if you want pagination in views to work. That is the biggest hurdle of all to overcome. It's fairly trivial to retrieve a result set and filter out the ones the user can't access; it's much harder to avoid retrieving the entire (potentially huge) list just so you can count how many the user can access.

On 3/12/15 3:16 PM, grahamtk wrote:
Given that visibility is a product of all pages in ancestry of a page, this sounds like a problem I have met before where we had different group memberships amounting to different sets of permissions. We solved it with a bitmask for the permissions for each group where each bit granted a given action. To find the sum of permissions this was done with a bitwise And (&) operator. Ofcourse here we have a sum of group permissions and page path ancestry so added level of complexity. 

Given a permission mask like this:
Read   _____________
Write   __________     |
Add     ______      |     |
Delete  ___     |     |     |
                1    1    1    1
Where 0 is deny and 1 is grant access 
$read_perms = 0001


The path permissions would be a bitwise and of all rows, meaning the first deny would deny access.  

But for each page there should be a bitwise or so the widest access a user posess is given precedence over more restricted access. 

So the access can be done like:
|   bitwise or
&  bitwise and

Front page;
Users group a             0 0 0 1
|
Users group b             0 0 0 1
=                                                0001  &

Subpage a;                
Users group a            0 0 0 1
Users group b            0 0 0 1
=                                                0001  &

Intrawebz frontpage.
Users group a             0 0 0 0
|
Users group b             0 0 0 0
=                                               0000  &
Articles page        
Users group a              0 0 1 1
|
Users group b              0 0 0 1
=                                               0011   &

0001
&
0001
&
0000
&
0011
=
$users_perms= 0000 

Access test: 
$users_perms
&
$read_perms
= no access. 

No idea if permissions in mm is implemented with bitmasks, but it would help my understamding if it was. 

Could i get a short summary of how permissions are stored and calculated in mm? 


---

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=713157

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