Summary / tasks
Current behavior: Only direct members of a space are notified when content is changed.
Produce a patch that allows for inherited members of a group/space to be notified when content is changed. This behaviour should be disabled by default, but can be enabled per Group.
Example desired behaviour: Space A inherits users from Group B. By default, only direct members of Space A are sent notifications. An admin ticks an 'Also notify inherited users' option on the settings for Space A. Now members of A and B are both notified.
Original report
I've been asked by end users to add the ability to target notifications to any member of space inherited groups as well.
I've not seen any way to implement this but by patching oa_notification module while updating the query of function 'oa_notifications_get_users_for_node'
from :
$query = db_select('users', 'u');
$query->rightJoin('og_membership', 'og', 'u.uid = og.etid');
$query->fields('u', array('uid', 'name'))
->condition('og.entity_type', 'user')
->condition('og.gid', $gid);
to:
$subquery = db_select('og_membership', 'og2');
$subquery->fields('og2', array('gid'))
->condition('og2.entity_type', 'node')
->condition('og2.etid', $gid);
$db_or = db_or();
$db_or->condition('og.gid', $gid)
->condition('og.gid', $subquery, 'IN');
$query = db_select('users', 'u');
$query->rightJoin('og_membership', 'og', 'u.uid = og.etid');
$query->fields('u', array('uid', 'name'))
->condition('og.entity_type', 'user')
->condition($db_or);
I know the question of users inherited from groups is already discussed for the space member listing panel (a shared request), but I think in the case of the notification form, the chosen select wouldn't involve same drawback.
Thanks for considering the suggestion and anyway for all the good work behind the OA2 jewel :)
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | notifications-for-inherited-users-2194169-13.patch | 1.46 KB | Anonymous (not verified) |
| #6 | notifications-for-inherited-users-2194169-6.patch | 1.54 KB | lukio |
| #3 | notifications-for-inherited-users-2194169-3.patch | 1.24 KB | lukio |
Comments
Comment #1
pjbarry21 commentedI'm hoping your patch suggestion might work for the issue I submitted a while back: https://drupal.org/node/2138739.
Have you applied this patch to your site?
Comment #2
lukio commentedComment #3
lukio commentedHi!
I created a patch with the work done by phKU.
I also apply other modifications. When the user select a group, the inherited users are also notificated.
Hope it helps!
Comment #4
Argus commentedComment #5
pjbarry21 commentedThanks! This does appear to work, but hoping we can tweak it a bit for our current setup.
We wanted to have groups inherit users from space members (so we can have notifications get sent to all space members and so all space members are automatically part of a group by using inheritance and eliminating the need to manually add users to groups AND spaces just to use the notifications feature).
But, with our configuration, we also have subspaces. With this patch, the notifications now go to the inherited space of the group we list in notifications (wonderful!), but if the space is a subspace, the notifications also go to the space above it (its "parent"). I've tried turning off the inherit users option within the spaces (at all levels) and it appears that it has no effect on who receives the notifications.
Is there a way the patch can be tweaked to only send notifications to the specific space members that are inherited by the group (and not the space's immediate parent, as well)? We plan to have a group that corresponds to each space, so if we want to send notifications to a subspace and its parent, we would just enter both of those groups in the notifications. For our implementation, not all members of the parent space are members of the subspaces.
Thanks, again for getting this patch together!
Comment #6
lukio commentedHi pjbarry21!
Now its checks if the field og_user_inheritance is active to send to the space and his parent.
Take a look, and let me know if it works for you.
Cheers!
Comment #7
jennjohnson commentedHi,
I've installed the patch (I'm on Pantheon, so using openatrium-7.x-2.12) and it's not working for me.
Perhaps I'm missing a step or another configuration setting? I thought maybe it was an order or events issue, so I backed everything out (my groups membership, etc) and started from scratch.
Created a group called All Members.
**Within the /node/add/oa-group form for this, I set "Group visibility" to "Private," chose no parents, checked "Yes" for "Groups user inheritance", checked "Inherit Permissions" for "Group user permission inheritance," and selected "Use default roles and permissions" for "Group roles and permissions."
Created a top level space called Home.
**Within the node/add/oa-space form for Home, I added my "All Members" group as parent, checked "Yes" for "Groups user inheritance," checked "Inherit Permissions" for "Group user permission inheritance," selected "Use default roles and permissions" for "Group roles and permissions," and added "All Members" to the "Notifications" block on the right. Also set "Group visibility" to "Private."
Created a section in that space called Discussions.
**Chose all default options, which included "All Members" already being shown (and greyed out) in the "Notifications" block.
Added two test users to the "All Members" group.
**These users were existing authenticated users, but were not members of other groups or spaces. (They could login, but got Access Denied.) Once I added them to this group, they could see the Home space.
Created a discussion in this space, but the only one notification was sent, and it was to the site admin account (that created the space), not either of the two test members.
Is there something missing from my configuration? Does my All Members "group" actually have the have the "space" as its parent rather than the way I have it?
Comment #8
jennjohnson commentedJust an update that notifications for inherited users are working when content is deleted, but not created content. Strange, but gives me some more clues for debugging my configuration. Hrmmm.
Comment #9
pjbarry21 commentedSorry for the delay... I've gotten swamped and haven't even had a chance to report back on the 2nd patch (it didn't fix the inheritance issue for me -- more later about that).
Yes, I think you're right in your last sentence -- the key difference I see from your post and mine (if I'm understanding your post correctly) is that in the GROUP, the part that binds it to the space members appears to be listing the space in the "Parents" field. So, for us, we have an "Operations Center" Space with content, sections and that's where we add the members (since we need to do that for their permissions in the space, anyway). We then create a Group called "Operations Center Members" (easier to spot the difference between the two when I throw "members" in there -- some views combine spaces and members automatically unless you do a specific filter and it was getting confusing). In the Operations Center Members Group, I add "Operations Center" Space as the Parent.
For us, the Operations Center Space is a subspace. So, when I applied the first patch, this config had caused all notifications to be sent to the Ops Ctr Space AND its immediate parent (that had not been listed anywhere except as a Space parent in the Operations Center Space (not the Group).
When I applied the 2nd patch, it still showed 25 people in the notification window (using the show details button) -- that's the total number of members of both the Ops Ctr Space and its parent. I planned to debug more (I recall that the notice at the top of the window was different, but hadn't had a chance to see what it meant), but started having problems with some other Open Atrium default views (spaces and sections with a block to show all sub-sections/pages started showing EVERY section on the site) -- so I pulled out both patches to try to rule out that being the cause. And I haven't had a chance to go back in and try all of this again. I plan to re-apply the patches after I clean up some other things and will let you know what I find.
Comment #10
mpotter commentedWhen working on this patch, it also needs some sort of per-space configuration option. There are many use-cases where you do *not* want to spam all of the members of the parent spaces with notifications so this needs to be something disabled by default (to match current behavior) but something that can be enabled on-demand.
We are actually working on improvements to the entire Notification widget so maybe we can find a place to add an option there, sort of like the "Do not notify for this update" checkbox where we can also provide ajax feedback on exactly who is about to be notified.
Comment #11
dsnopekUpdating title to better reflect exactly what this patch is doing. And, updating status per Mike Potter's comments.
Comment #12
jkingsnorth commentedMarked #2520408: Allow inherited users to be notified as duplicate - there is a temporary workaround suggested in that issue.
Marked #2296441: Notifications for groups do not work as expected as duplicate too.
I've also updated the issue description with the remaining tasks.
Comment #13
Anonymous (not verified) commentedThis path will apply to the current version 2.54
Comment #14
mpotter commentedClosing this issue since the new 2.60-rc1 version has a new notification system that allows you to add inherited groups and users to notifications.
Comment #16
silvaf6 commentedHi.
Where is the new option to let inherited groups and users to receive notifications? Can't find it anywhere.
Thanks in advance.