Pre-defined group "all logged-in users" regeneration?

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

Pre-defined group "all logged-in users" regeneration?

Hilary Caws-Elwitt

Hi everyone,

 

We just started using the pre-defined group “All logged-in users,” and found that it was not working--when assigned to a page, logged-in users still lacked permissions, both by testing and in checking  the solve permissions issues table. What fixed it was re-saving (without changes), to force it to regenerate on the next cron run.

 

The MM menu “Redo virtual groups” didn’t seem to do anything; it immediately returned “Virtual groups have been regenerated” but didn’t make a difference. On my test instance where I have not re-saved the group, mm_virtual_group still has just one row after the command, for user 1. On the instance where the group was re-saved and rebuilt through cron, it has a row for each user.

 

Does “Redo virtual groups” not cover this group for some reason, or is there something I should investigate? More generally, under what conditions would you normally invoke that command, and/or should I check the “all logged-in users” one periodically?

 

Thanks!

--

Hilary Caws-Elwitt

IT Analyst - Five Colleges, Inc. - http://www.fivecolleges.edu

97 Spring St, Amherst MA 01002

[hidden email] - 413-542-4022

 

---

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

(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: Pre-defined group "all logged-in users" regeneration?

Dan Wilga-2
Hi Hilary,

In order for a virtual group to be regenerated, it has to have its
"dirty" field in the mm_vgroup_query table set to 1. It's up to whatever
makes a change that would alter the query's results to set the dirty
flag. MM doesn't really know that this particular query is associated
with the users table, so if you want to rely on this happening you could
add something to a custom module of your own, like this (untested):

function mymodule _user_update() {
mymodule_mark_dirty();
}

function mymodule_user_insert() {
mymodule_mark_dirty();
}

function mymodule_mark_dirty() {
db_update('mm_vgroup_query')
->fields(array('dirty' => 1))
->condition('qfrom', 'FROM {users} WHERE uid > 0')
->execute();
}

Obviously, this will fail to update if somebody alters the stock query
in the virtual group.

Thinking about this some more, I guess I could add this exact code to
MM. Consider it a feature request.

On 3/31/14, 2:53 PM, Hilary Caws-Elwitt wrote:

>
> Hi everyone,
>
> We just started using the pre-defined group “All logged-in users,” and
> found that it was not working--when assigned to a page, logged-in
> users still lacked permissions, both by testing and in checking the
> solve permissions issues table. What fixed it was re-saving (without
> changes), to force it to regenerate on the next cron run.
>
> The MM menu “Redo virtual groups” didn’t seem to do anything; it
> immediately returned “Virtual groups have been regenerated” but didn’t
> make a difference. On my test instance where I have not re-saved the
> group, mm_virtual_group still has just one row after the command, for
> user 1. On the instance where the group was re-saved and rebuilt
> through cron, it has a row for each user.
>
> Does “Redo virtual groups” not cover this group for some reason, or is
> there something I should investigate? More generally, under what
> conditions would you normally invoke that command, and/or should I
> check the “all logged-in users” one periodically?
>
> Thanks!
>
> --
>
> Hilary Caws-Elwitt
>
> IT Analyst - Five Colleges, Inc. - http://www.fivecolleges.edu 
> <http://www.fivecolleges.edu/>
>
> 97 Spring St, Amherst MA 01002
>
> [hidden email] <mailto:[hidden email]> -
> 413-542-4022
>
> ---
>
> You are currently subscribed to monster_menus as:
> [hidden email] <mailto:[hidden email]>.
>
> To unsubscribe click here:
> http://lists.middlebury.edu/u?id=685500.19fa7de7038497527f6a88cf1629251d&n=T&l=monster_menus&o=700198
>
> (It may be necessary to cut and paste the above URL if the line is broken)
>
> or send a blank email to
> [hidden email]
> <mailto:[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=700231
or send a blank email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Pre-defined group "all logged-in users" regeneration?

Hilary Caws-Elwitt
In reply to this post by Hilary Caws-Elwitt
Thanks, Dan, that would be fantastic! Am I correct in saying that otherwise the pre-defined group isn't very helpful for sites where users are added continuously? It looks like without the "dirty" field set, we'd have to constantly resave the group to include new users. The bunch of new users since I resaved yesterday are not in the table, so either that's the case, or we have something else misconfigured...
--
Hilary Caws-Elwitt
IT Analyst - Five Colleges, Inc. - http://www.fivecolleges.edu
97 Spring St, Amherst MA 01002
[hidden email] - 413-542-4022

-----Original Message-----
From: Dan Wilga [mailto:[hidden email]]
Sent: Monday, March 31, 2014 8:43 PM
To: Monster Menus Development
Subject: Re: Pre-defined group "all logged-in users" regeneration?

Hi Hilary,

In order for a virtual group to be regenerated, it has to have its "dirty" field in the mm_vgroup_query table set to 1. It's up to whatever makes a change that would alter the query's results to set the dirty flag. MM doesn't really know that this particular query is associated with the users table, so if you want to rely on this happening you could add something to a custom module of your own, like this (untested):

function mymodule _user_update() {
mymodule_mark_dirty();
}

function mymodule_user_insert() {
mymodule_mark_dirty();
}

function mymodule_mark_dirty() {
db_update('mm_vgroup_query')
->fields(array('dirty' => 1))
->condition('qfrom', 'FROM {users} WHERE uid > 0') execute();
}

Obviously, this will fail to update if somebody alters the stock query in the virtual group.

Thinking about this some more, I guess I could add this exact code to MM. Consider it a feature request.

On 3/31/14, 2:53 PM, Hilary Caws-Elwitt wrote:

>
> Hi everyone,
>
> We just started using the pre-defined group "All logged-in users," and
> found that it was not working--when assigned to a page, logged-in
> users still lacked permissions, both by testing and in checking the
> solve permissions issues table. What fixed it was re-saving (without
> changes), to force it to regenerate on the next cron run.
>
> The MM menu "Redo virtual groups" didn't seem to do anything; it
> immediately returned "Virtual groups have been regenerated" but didn't
> make a difference. On my test instance where I have not re-saved the
> group, mm_virtual_group still has just one row after the command, for
> user 1. On the instance where the group was re-saved and rebuilt
> through cron, it has a row for each user.
>
> Does "Redo virtual groups" not cover this group for some reason, or is
> there something I should investigate? More generally, under what
> conditions would you normally invoke that command, and/or should I
> check the "all logged-in users" one periodically?
>
> Thanks!
>
> --
>
> Hilary Caws-Elwitt
>
> IT Analyst - Five Colleges, Inc. - http://www.fivecolleges.edu 
> <http://www.fivecolleges.edu/>
>
> 97 Spring St, Amherst MA 01002
>
> [hidden email] <mailto:[hidden email]> -
> 413-542-4022
>
> ---
>
> You are currently subscribed to monster_menus as:
> [hidden email] <mailto:[hidden email]>.
>
> To unsubscribe click here:
> http://lists.middlebury.edu/u?id=685500.19fa7de7038497527f6a88cf162925
> 1d&n=T&l=monster_menus&o=700198
>
> (It may be necessary to cut and paste the above URL if the line is
> broken)
>
> or send a blank email to
> [hidden email].
> edu
> <mailto:[hidden email]
> dlebury.edu>
>


---
You are currently subscribed to monster_menus as: [hidden email].
To unsubscribe click here: http://lists.middlebury.edu/u?id=1034715.d8dc340b0014c740c37e95754e54e1f3&n=T&l=monster_menus&o=700231
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=700263
or send a blank email to [hidden email]
Loading...