send mail when new ticket is created

[roger@…]

It would be handy to allow a user to select to receive a message when a new ticket (or wiki page or whatever) is created. Then they could elect to Watch This item. If they are not interested, they do nothing.

As it is now, they do get these creation messages. Unfortunately, in order to get these, they also get messages about tickets in which they are not interested. Getting notifications on creation only would allow users fine-grained control over what they get messages about. We have users who want to follow some ticket activity that they did not originate and will not contribute to. The current setup does not allow them to get messages about ticket creation without also getting messages about all other ticket activity.

[Ryan J Ollos]

#10627 is related, as a milestone create subscriber is planned as part of the implementation. That might serve as a pattern for more fine-grained create/modify/delete subscribers for each resource.

[Ryan J Ollos]

Also related: falkb recently requested notify me when a ticket that I updated is modified in ​this mailing list post. Actually, he requests the inverse don't notify, which I think we already satisfy.

If we add many more rules, I think the preferences panel will need to eventually be simplified:

rule	created	updated	deleted	resolved
notify me when a ticket I own is
notify me when a ticket I reported is
notify me when any ticket is

Well, I don't think that is a perfect idea, but I'm hoping it serves the purpose as forming a point of discussion that could lead to better and more refined ideas. You can see how one might want even more flexibility. In the example shown, just imagine adding a column for every ticket action (assigned, reopened, ...), and then dream up more rules and even more dimensions to the configurability (e.g. ticket milestone changed, different resolution states, ... ;) We have to keep it simple enough, but there will always be good arguments for more and finer-grained rules - e.g. the project manager only wants to be notified when a ticket's milestone is changed, a ticket's custom field named due date is changed and when tickets are resolved as fixed ... seems reasonable, right?

[falkb]

Replying to rjollos:

Also related: falkb recently requested don't notify me when a ticket that I updated is modified ... I think we already satisfy.

Yes, I realised that works, AnnouncerPlugin is not that noisy as Trac's default notification system.

If we add many more rules, I think the preferences panel will need to eventually be simplified:

I second your idea to replace the combobox by a matrix of checkboxes. Though I also want to remark a certain group of users is quickly overstrained if they see more than 5 things at once, I mean such matrix is more for experts. It's always a trade-off between flexibility and simplicity, that's why what about offering only a few scenarios (quit, ..., noisy), and more fine-granular by your checkbox-table on a sub page "adapt to user defined behaviour" which then will be added as new scenario ... In principle like the desktop theme customization on Windows 7, you know what I mean.

[anonymous]

By fine grained, I really meant at the level of the ticket/wiki page/etc. The existing 'Follow This' is enough. The problem is that you don't know there is a ticket to potentially follow unless you get all ticket activity. Just being able to find about the creation of something makes a lot of things possible for the user with the current state of things. Currently, to find that out, you will find out lots about tickets in which you have no interest.

The next step of following all things that can happen is more than I would expect. Given that work flows can be rather complicated with perhaps many states, a menu to track those state changes would be a very unruly monster!

[Ryan J Ollos]

Replying to anonymous:

The next step of following all things that can happen is more than I would expect.

Right, and your request is very reasonable, but my point is that next along comes someone else with a very reasonable request that is slightly different from yours that warrants one or more additional rules, for example, to only want to know when tickets are closed, so we need to consider how in the long run we can support so many different configuration options in a clean way, and without overwhelming the user and administrator.

[Ryan J Ollos]

Replying to falkb:

It's always a trade-off between flexibility and simplicity, that's why what about offering only a few scenarios (quit, ..., noisy), and more fine-granular by your checkbox-table on a sub page "adapt to user defined behaviour" ...

Yes, I like the idea of having simple and advanced configuration views, and predefined configurations for the simple view. We should definitely keep that in mind.

[falkb]

Replying to rjollos: ... and then dream up more rules and even more dimensions to the configurability (e.g. ticket milestone changed, different resolution states, ... ;) We have to keep it simple enough ... snip

For instance, I have a concrete request here: to have automatic notification emails on ticket creation when its ticket custom field 'project' meets one of the values the user has subscribed to... Is is imaginable to marriage that with your suggested checkbox table? I suppose such wishes from real life could help to find out if the implementation is generic enough.

[Steffen Hoffmann]

I don't think, that the IAnnouncementPreferenceProvider should be (ab)used for generating more advanced (read: complicated) custom subscription preferences. It simply doesn't scale well, because all field values are reflected in session_attribute. Announcer's shift to the current subscription model has obsoleted many of these entries, and I hope to reduce their number even more.

That said, I'm not at all against the idea of allowing more subscription customization. Quite the contrary is true. I've been following the discussion closely. When my feature bloat alarm bell rang, I drafted a proposal for optionally adding almost arbitrary conditions to any subscription that fits into the new subscription model. But I won't disclose more before in-deep discussion and before I have a working prototype as a proof-of-concept.

[roger@…]

Just keep in mind that the birth of an item is a special thing. Knowing about those allows you to perhaps even use other tools to manage things. You cannot act on something until you know that it exists. That is why I singled that out.

[Steffen Hoffmann]

Replying to roger@opq.se:

Just keep in mind that the birth of an item is a special thing. Knowing about those allows you to perhaps even use other tools to manage things. You cannot act on something until you know that it exists. That is why I singled that out.

Agree. Announcer has the privilege to know a bit about transitions, i.e. for tickets there are property changes readily available in the Ticket object supplied by the change listener. For other Trac realms it might not be that straight-forwards, and we may need to look-up relevant information from resource's history, or never get a clue for items, that lack revision support (i.e. attachments, milestones).

Therefor starting with ticket subscribers should yield the most feature-rich and efficient use of subscription constraints. I'm working on this feature here. It's constraint editor will borrow much code from TracQuery ones, but transitions are the outstanding new constraint, that will resolve your demand here. Sure, we must have it for ticket status, but may want it for a number of other fields too.

Speaking more about the upcoming conditional subscriptions I got struck by an unexpected idea: This might be the road towards subscriber consolidation. I.e. while we use one of AllTicketSubscriber, TicketOwnerSubscriber, TicketReporterSubscriber or TicketCustomFieldSubscriber today, we may just pick the AllTicketSubscriber and add (OR-ed) constraints like

• user (me) == owner (yields notification equal to TicketOwnerSubscriber)
• user (me) == reporter (yields notification equal to TicketReporterSubscriber)
• user (me) ~= custom cc-field (yields notification equal to TicketCustomFieldSubscriber)

according to our needs. You see? We may want to keep the current, rather lengthy list if subscription options as the 'simple' way (predefined constraints + 'always'/'never') compared to the one that we'll get with the subscription adverb 'conditional' (new constraint editor). I'll disclose a screen-shot of my vision to explain a bit more, what I'm talking about here.

Have to keep an eye on good default values, but it addresses my worries about feature bloat rather nicely. Even more I'm quite convinced, that this is the missing piece for completing the already great subscription model. Thanks for pushing the issue.

[Steffen Hoffmann]

The attached screen-shot​ shows subscription user preferences with minor tweaks (text-less method buttons for rule deletion and up/down order changes) as well as the filter section for a conditional subscription matching only tickets that just got closed.

[Steffen Hoffmann]

preliminary design of conditional subscriptions for AnnouncerPlugin user preferences

[Ryan J Ollos]

Replying to hasienda:

The attached screen-shot​ shows subscription user preferences with minor tweaks (text-less method buttons for rule deletion and up/down order changes)

This seems like a very nice enhancement on its own, so definitely +1 for this, and I suggest considering to push this change prior to the other more time consuming changes discussed in this ticket. The old style buttons just didn't look right, particularly with Trac 1.0.

as well as the filter section for a conditional subscription matching only tickets that just got closed.

Looks great. Is this meant to be a very specific example of how filters could be applied? My head is swimming with other possibilities :) Are you also envisioning filters for, e.g. the any ticket part? Conditionally notify me when a ticket with Component = AnnouncerPlugin and Type = defect changes. I have no idea how we can make all this layout nicely, but your association with ticket query was brilliant.

[falkb]

+1 from me

... just one thing I don't understand is the checkbox in 'Previous values'... ? ...

[Steffen Hoffmann]

Replying to falkb:

+1 from me

Thanks to both of you for encouraging these changes in general.

... just one thing I don't understand is the checkbox in 'Previous values'... ? ...

The hint below says: Don't care, if you're not after transitions. If only current (== new values) of a ticket are of concern, just leave it all empty/unchecked. A totally empty section will not only be possible, its probably the default to start from, if you choose 'conditionally' instead of 'always' or 'never'.

In the example screen I demonstrate a standard trigger-like configuration. You have to configure before/after here, but I think that's still pretty clear.

Furthermore I've found, that new tickets are yet another case. Mathematically explained the ticket is initialized, going from all-None/all-NULL values, but I can't imagine to make this a real option that could be understood - intuitively - even by advanced users. So I suggest to just check that checkbox, if you require notification for only new tickets. Clearer?

[falkb]

Replying to hasienda:

... if you're not after transitions...

This is the actual problem. I didn't understand what it means, and in such case one can't understand the checkbox. You should explain it in a clearer hint. A common user doesn't understand what you mean with a transition.

[falkb]

Do I understand attachment:20121120_announcer_pref-subscriptions_conditional-subs_preview.png​ right that one gets mail only for the special case when the state changes from accepted|assigned|new|reopened to closed?

[Steffen Hoffmann]

Replying to rjollos:

Replying to hasienda:

The attached screen-shot​ shows subscription user preferences with minor tweaks (text-less method buttons for rule deletion and up/down order changes)

This seems like a very nice enhancement on its own, so definitely +1 for this, and I suggest considering to push this change prior to the other more time consuming changes discussed in this ticket. The old style buttons just didn't look right, particularly with Trac 1.0.

It was more for making them smaller, accessible at a distinct place in front instead of behind subscription description texts of very different length. But you're probably right about the more contemporary design, if used with current stable. Note though, that I added a bare minimum of additional style definitions yet. Most styles are meant to be inherited from Trac core, what especially applies to text block and button design.

as well as the filter section for a conditional subscription matching only tickets that just got closed.

Looks great. Is this meant to be a very specific example of how filters could be applied? My head is swimming with other possibilities :) Are you also envisioning filters for, e.g. the any ticket part?

Only thing, that is NOT in there right now, is the ticket ID. I think, we shouldn't mix WatchSubscriber with the rest, because it'll require a view on it's own. Already a dozen watched items/item groups would overcrowd the subscription list, not to speak of hundreds of items. I'm still after WatchlistPlugin integration for this specific subscriber.

Anyway, the selection now is always|conditional|never for EVERY available subscriber, even if it wouldn't be sensible for AcctMgr notifications to have a filter on ticket properties. I'll rather implement the old row of checkboxes from the IAnnouncementPreferenceProvider there. So probably just on filter per Trac realm (ticket/wiki/...).

Conditionally notify me when a ticket with Component = AnnouncerPlugin and Type = defect changes. I have no idea how we can make all this layout nicely, but your association with ticket query was brilliant.

In ticket-related subscription you'll set it as easy as you would in the custom ticket query. I think, that making it as similar as possible is the best way to make it intuitive - well at least to Trac people.

Guess, it would be sensible to create a new supplementary wiki page below AnnouncerPlugin/ with more use-cases to show the upcoming code in action, right? After I've made progress on the actual implementation up to the point, where I can just snapshot configurations from the real web-UI without GIMP mods, I'll do.

[Steffen Hoffmann]

Replying to falkb:

Do I understand attachment:20121120_announcer_pref-subscriptions_conditional-subs_preview.png​ right that one gets mail only for the special case when the state changes from accepted|assigned|new|reopened to closed?

Yes, that's the essence. Other changes are optional, meaning, that they may happen. So the status change is the only requirement for the notification to happen. And of course you may add additional constraints to the 'Current values' section, to i.e. only care for closing of tickets owned/not owned by you.

Same for new tickets: Check 'alternatively require a new ticket' (feel free to suggest a better label) and setup 'Owner' constraint in the 'Current values' section below to get only matching new ticket notification.

Configuration possibilities are practically endless, so more examples will be require to show-case this new feature as hinted in a previous comment of mine.

[falkb]

I suggest to change the labels:

• from "Previous values" to "from"
• from "Current values" to "to"
• "alternatively require a new ticket" to "or on new ticket creation"

and then I read

conditionally notify me when any ticket changes
from
    ...
   or
    on new ticket creation
to
    ...

which makes things clearer IMHO.

[Steffen Hoffmann]

updated preview incorporating label text as suggested by falkb in comment:19

[Steffen Hoffmann]

I did it​, and while slightly bigger, the structure seems clearer indeed. I tried to improve the general hint about the 'from' section too. Thanks for review and your suggestions.

[falkb]

LikeIt++

[Steffen Hoffmann]

Another point for discussion is the default filter, meaning the initial filter configuration right after adding a 'conditionally' subscription. Some options:

• exactly empty
• common 'status' choice option with everything but 'closed' preselected
• ...

The inverted "just-status" (only 'closed') is shown in both previews, with extra selection for previous values.

Opinions? Suggestions?

[anonymous]

the initial filter config should probably reflect the current behaviour of a standard Trac installation, for having a seamless changeover

[Steffen Hoffmann]

Replying to anonymous:

the initial filter config should probably reflect the current behaviour of a standard Trac installation, for having a seamless changeover

The default query is for own, open tickets. For default (ticket) filter it would be equivalent to

• reporter=username
• status!=closed (or the respective status selection)

so this is what you suggest?

[Steffen Hoffmann]

#11178 has been closed as a duplicate of this ticket.

[Ryan J Ollos]

Please upgrade to Trac 1.2, which has integrated the core of AnnouncerPlugin. Please raise the issue on the ​trac:MailingList if you encounter the issue with Trac 1.2.

See ​trac:#6613.