hi, i just realized that this feels like it's intended for small audience sites - like a company or small project team of a few dozen users at most - because my understanding is that if enabled and users are given access, then (based on role anyways, assuming here that "all can use it") - then a user could randomly send auto-subscribe stuff to every site user...

i made an earlier request about integration with User Relationships - that's one way to constrict what 'team' means - but is there anything in the works that may allow for a user to build a "team" on the fly and get confirmation from users before being allowed to sign them up for everything?

technically, an OG could be a team, but since OG notifications already does waht this module does (in terms of OG notifications as well as OG broadcast for use by OG admins), the real benefit would be organizing 'others' outside of the OG - after looking it over again, something like user relationships as a filter is the only logical next step in terms of using this on a large site (like "tell all of my friends i wrote something, not just the others in this OG" at which point user sees all friends not affiliated with just the OG's he's part of)

does that make sense? or am i misunderstanding the intended audience and usage for this module?

Comments

David Goode’s picture

David Goode CreditAttribution: David Goode commented

Hello,

This pre-release module was originally created for a team collaboration site with a small number of trusted users, so your intuition as well as the module's description are both accurate. However, it is not exclusive to this use case, and the OG integration and contextual limitation is a large part of that. OG doesn't replicate its functionality to my knowledge. A user can subscribe themselves to a node and receive the exact same notifications this module sends, in or out of a group, but the difference is that other users, and even admins for that matter, often have no easy way to subscribe others. The User Relationships idea is intriguing, but as I said previously I'm not familiar with that module, and it sounds like a fairly extensive addition which I probably won't be able to undertake. Adding something like what you describe may not be difficult under the framework of the Relationships module, but the permission issues might be more arduous, as would reimplementations of the maintenance and unsubscription capabilities of this module. Any extension modules or code additions are more than welcome however, in this area and others, and if to that end you or others need my input on specific areas I would be glad to help.

Thanks,
David Goode

zilla’s picture

zilla CreditAttribution: zilla commented

thanks david. to be honest, it's a perfect module for business class users - may be worth clarifying on the project page in a positive way!

for example, with role based usage, this could be a perfect way for a group of site admins/moderators to communicate around nodes and content and alert one another (could be a companion to flag, etc)

one question - and maybe this is more of a feature request if it's not already there - if only a certain role is given access to use the module (e.g. user type 'site editors' versus just 'authorized'), will this module by default limit the availble users to just the other names of users in that role?

if such simple permission were possible (respecting the class of authorized user), then this truly would allow for creation of teams on the fly with one future enhancement (a real 'down the road' idea) - the ability to sort of 'clone' the module so that a site admin could create new 'teams' which would really be 'classes of users' - an example:

imagine your company now grows to 100 people, 20 each in finance, sales, marketing, operations and admin

one 'team' is created for all - this is the ability to send to any or all or some across all 100
one team is created for each group of 20 - technically just a 'user type' alongside 'authenticated' like 'sales' (admins can assign or use a module to let users move in on their own)
at that point, any member of such dept. could effectively broadcast a message *without* using notificaitons module by simply selecting 'sales' (all recipients, hence all users in that user role type)
*note: this is what i meant by replicating some of OG - for example, there could just be an OG for sales, for marketing and so on, and all notifications would in turn be constrained BUT what your module makes possible is what OG lacks: the ability to post in *another* group and still alert the members of my main group (meaning i'm a sales team talking to marketing team and want to alert all sales team of the dialogue - if there were an OG for mktg, the OG for sales member would never see it, ever, unless they manually go and find it - that is a serious and compelling distinction for business use - like engineering talking to marketing, etc !!!)

that's the basic idea - same exact thing as what you're doing now but with a kind of 'clone this module' feature for new user types...

i may actually bring this up over at the user relationships module forum because they've got lots of contribs rolling in, and other modules like private messaging are already tinkering with the UR api to make the 'friends list' appear - and it's particularly well suited to your module because it allows for one and two way relationships, categories (like friend, manager, etc) and implied relationships (if you're my manager, i'm your subordinate and hence within your dept, etc)

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented
Version: 6.x-1.x-dev » 6.x-2.x-dev

We're looking to add exactly this functionality to a site of ours, but our teams are not based on og groups, they are custom to our site, and live in their own table etc. etc.

Would you be up for refactoring some of the code so that instead of just checking for og and running a different query if it's around, using a drupal_alter at some point to define what constitutes a team?

David Goode’s picture

David Goode CreditAttribution: David Goode commented

Hey! Yeah I'd definitely be open to such a patch if it isn't implemented too invasively. Some people have also asked about using user relationships and other modules to group users, so ideally this would be sufficiently flexible to handle that. Maybe make notifications_team implement a hook for filtering or adding to the user array it gives subscriptions for, and then make a couple implementations of it? The only place it really does this is where it finds the list of users, which now uses a somewhat ugly sql query, and where it passes the info to the autocomplete callback.

David

hanoii’s picture

hanoii
Primary language Spanish
Location 🇦🇷UTC-3
CreditAttribution: hanoii commented

Probably some relation to #367960: Role notifications. Just surfing through this module's issue queue into role notifications, will propose a quick solution I might work on on the related issue I just mentioned. Anyone here still interested may check in there and see if we can update this discussion a bit.

Also feel free to mark this one as duplicate if the other discussion makes more sense or add to it so we don't have multiple issues on the same subject. I am still wondering if it is the same subject though for this one.