On Friday, May 12, 2017 at 9:13:38 AM UTC-7, Peter Suter wrote: > > On 12.05.2017 05:12, RjOllos wrote: > > > > On Tuesday, May 9, 2017 at 1:51:58 PM UTC-7, Peter Suter wrote: >> >> You could test JoinableGroupSubscriber: >> >> https://trac.edgewall.org/ticket/11870#comment:3 >> >> https://trac.edgewall.org/browser/psuter.hg/tracopt/notification/joinable_groups.py?rev=10397 >> https://trac.edgewall.org/attachment/ticket/11870/watch-prefs.png >> >> Regards, >> Peter >> > > > I can also see how it would be desirable to CC a permission group, and > have all members of the group receive an email. Without accounting for > overlapping user and group name,s here is a > > > Yes, that could make a lot of sense. > > simple patch to demonstrate (against 1.2-stable): > > diff --git a/trac/ticket/notification.py b/trac/ticket/notification.py > index 92957d016..589fdbb41 100644 > --- a/trac/ticket/notification.py > +++ b/trac/ticket/notification.py > @@ -29,6 +29,7 @@ from trac.notification.compat import NotifyEmail > from trac.notification.mail import (RecipientMatcher, create_message_id, > get_from_author, set_header) > from trac.notification.model import Subscription > +from trac.perm import PermissionSystem > from trac.ticket.api import translation_deactivated > from trac.ticket.model import Ticket > from trac.util.datefmt import (datetime_now, format_date_or_datetime, > @@ -462,6 +463,13 @@ class CarbonCopySubscriber(Component): > if 'fields' in event.changes and 'cc' in event.changes['fields']: > cc_set.update(to_set(event.changes['fields']['cc']['old'])) > > + # Get members of permission groups > + groups = PermissionSystem(self.env).get_groups_dict() > + for cc in cc_set.copy(): > + if cc in groups: > + cc_set.remove(cc) > + cc_set.update(groups[cc]) > + > matcher = RecipientMatcher(self.env) > klass = self.__class__.__name__ > sids = set() > > If we don't want this to be the default behavior, we could use similar > logic to create a CarbonCopyGroupSubscriber. In the case of a group that > has the same name as an sid, we'd have to decide which takes precedent, and > should log a warning. As far as I'm concerned, CarbonCopyGroupSubscriber > could just go in trac.ticket.notification rather than tracopt.notification, > since it wouldn't be enabled by default anyway. > > > The JoinableGroupSubscriber linked above inherited one more "trick" from > Announcer[1]: > > Add the group name preceded by @ (such as @security for the security > group) to the CC field of a ticket to notify all group members > Maybe this helps with the ambiguity / precedence question of overlapping > user / group names. > (But I can imagine requireing @group reduces "discoverability" / > "rememberability" of the feature. > Unless the groups are known to a auto-completion suggestion dropdown > feature.) > > I don't really know the benefits / disadvantages of using tracopt or not. > I don't mind either way. Do many users know to look for optional components > in tracopt / trac? >
I've been concerned that the visibility is not so great. We should probably review what's in there and try to point to it from the documentation, like the edit in: https://trac.edgewall.org/wiki/TracTickets?version=79 > Also, from a user perspective, I wonder if it would then make sense to > move "Group Membership" into its own admin panel. > Yes, I think so. I'm unsure how much we should do incrementally, prior to adding a user management page along the lines of what AccountManagerPlugin provides. > At the moment these groups are really "Permission Groups". > But with this feature they kind of seem to become more general "User > Groups" instead. > A normal user probably wouldn't know that "User Groups" are implemented as > permissions and can be found in the "Permissions" admin panel. > > If "Permission Groups" are implemented, does it make sense to also > implement "Joinable Groups", or would the former replace the latter? > Advantages: > * Users without PERMISSION_GRANT/_REVOKE can join and leave them freely. > * You can organize permissions independently from notifications. > Disadvantage: > * There are now confusingly two quite similar user group notification > systems. > * You have to organize the permission groups AND the notification groups. > Maybe these group structures are often identical? > I'm not sure either. Potential pathway is: 1. Modify CarbonCopySubscriber to allow permission groups to be CC'ed 2. Add joinable groups 3. Add a "real" group class and associated views, and modify the permission system and joinable groups to use the class. I created a ticket to consider the change: https://trac.edgewall.org/ticket/12808 - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
