email notification for previous updaters

[Brettschneider Falk]

Hi,
"always_notify_updater" in section [notification] of trac.ini is documented as "Always send notifications to the person who causes the ticket property change and to any previous updater of that ticket."

Can I somehow switch off notification for "any previous updater"? Instead I want to leave this decision to the user who can add himself to 'CC'.

CU, F@lk

----
Falk Brettschneider
R&D Software
Baumer Optronic GmbH
www.baumer.com



Gesch?ftsf?hrer: Dr. Albert Schmidt* Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE 189714583

[RjOllos]

On Wednesday, November 14, 2012 2:13:09 AM UTC-8, F@lk wrote:

Hi,
"always_notify_updater" in section [notification] of trac.ini is documented as "Always send notifications to the person who causes the ticket property change and to any previous updater of that ticket."

Can I somehow switch off notification for "any previous updater"? Instead I want to leave this decision to the user who can add himself to 'CC'.

No (1), but I was looking at this recently while working on (2), and thinking the options should be separated. If you open a ticket, I'd implement it as a follow-on to #2311. Getting interest from a Trac committer to accept the change might be more challenging. You will probably have better luck switching to the AnnouncerPlugin and getting the behavior implemented there, if it doesn't already exist.

(1) http://trac.edgewall.org/browser/trunk/trac/ticket/notification.py?rev=11331&marks=99-104#L77

(2) http://trac.edgewall.org/ticket/2311

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.11.2012 20:05, RjOllos wrote:
> Getting interest from a Trac committer to accept the change might be
> more challenging.

There are two new developers in town, that already contributed
significant changes, and I know of Peter even asking about need for
support to do things on the AnnouncerPlugin to TracNotification effort,
but this happened some months ago. It's a pity, that I wasn't able to
react and involve him at that time.

> You will probably have better luck switching to the
> AnnouncerPlugin and getting the behavior implemented there, if it
> doesn't already exist.

What sounds like 'flee to Easy street', is a good advice indeed, because
we have announcer.subscribers.TicketUpdaterSubscriber ("Allows updaters
to subscribe to their own updates."). Despite being used more often to
opt-out from change notifications for own changes, it can certainly do
the inverse thing - thats the flexible subscription system.

Try it, help improve it, make it move into Trac core.

You're interest and contribution (even just testing and review) is welcome.

Not though, that full backwards-compatibility down to Trac-0.11 is still
pending to happen. Now it works for Trac-0.12 and beyond "only".

Sincerely,

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCj9r0ACgkQ31DJeiZFuHfN+ACfRQGEmgmTVj43v3i8lXsO8opR
A/EAn1ZlbuZRsQHz1zIzJBGSVqZy7oC5
=AD80
-----END PGP SIGNATURE-----

[RjOllos]

On Wednesday, November 14, 2012 11:53:45 AM UTC-8, hasienda wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.11.2012 20:05, RjOllos wrote:
> Getting interest from a Trac committer to accept the change might be
> more challenging.

There are two new developers in town, that already contributed
significant changes, and I know of Peter even asking about need for
support to do things on the AnnouncerPlugin to TracNotification effort,
but this happened some months ago. It's a pity, that I wasn't able to
react and involve him at that time.

I should explain what I meant by my comment. The reason I said that getting the change accepted might be challenging is that I've seen several comments from the developers that suggest we need a full rework of the notification system, such as replacement with the AnnouncerPlugin, rather than fixing the existing notification system here and there. Therefore I wouldn't be surprised if a patch for ticket.notification was given low priority.

[Remy Blank]

RjOllos wrote:
> I should explain what I meant by my comment. The reason I said that
> getting the change accepted might be challenging is that I've seen
> several comments from the developers that suggest we need a full rework
> of the notification system, such as replacement with the
> AnnouncerPlugin, rather than fixing the existing notification system
> here and there.

It's not that we *need* a rework, but since there was a proposal for
integrating the AnnouncerPlugin, it was difficult to find motivation for
fixing the existing system, as it would have been wasted effort.

The proposal didn't materialize, and if there's no plan to revive it in
the near future, it may make sense to go back to the current system and
improve it.

(Of course, this comes from someone who couldn't find much time for Trac
in the last few months, so please don't take this as any kind of
endorsement.)

-- Remy

[RjOllos]

On Wednesday, November 14, 2012 1:10:26 PM UTC-8, Remy Blank wrote:

It's not that we *need* a rework, but since there was a proposal for
integrating the AnnouncerPlugin, it was difficult to find motivation for
fixing the existing system, as it would have been wasted effort.

The proposal didn't materialize, and if there's no plan to revive it in
the near future, it may make sense to go back to the current system and
improve it.

I think that Steffen and I would both like to revive the proposal, but I also think there is value in addressing some of the more undesirable behavior with the existing notification system, such as #2311, in the meantime.

 

(Of course, this comes from someone who couldn't find much time for Trac
in the last few months, so please don't take this as any kind of
endorsement.)

I'll continue to submit patches and hope for the best ;) 

[Peter Suter]

On 14.11.2012 20:53, Steffen Hoffmann wrote:
> I know of Peter even asking about need for
> support to do things on the AnnouncerPlugin to TracNotification effort,
> but this happened some months ago.

(15 months!?)

As Remy hinted at, the existence of AnnouncerPlugin and the integration
proposal seems to paralyse development on TracNotification.
Improving the existing system is not only wasted effort, it also makes
replacing it harder and less urgent. So improving the current system is
counter-productive if your real goal is integrating Announcer. :-/

To me it seems really unfortunate that Announcer and TracNotification
are so separate, incompatible, and (until recently) kind of dead. So a
few weeks ago I started working again on a more concrete, piece-by-piece
integration proposal. This has been put on hold for now, also because I
noticed you heavily hacking on Announcer again!

But since this topic is coming up now, here's a short overview of my idea:

1) Deprecate the old "high-level" system, don't heavily change or
integrate it with new functionality. But keep the "low-level" code and
configuration.

2) Dissect Announcer into topical parts. So far I identified:
* Extension API for Mail/Distribion
* Subscription DB & extension API, and "old" ticket subscriptions
* Modular preference pages
* New ticket subscriptions (Joinable ticket groups and components)
* Permission filters
* HTML emails
* Wiki notifications
* Attachment notifications
* Watchable resources
* Background delivery thread
* SMTP-over-SSL
* GPG encryption

3) Start integrating one of these and see how that is going.

(Some of those parts could/should possibly remain plugins forever.)

But as I said, that was before you revived work on AnnouncerPlugin.

What would be your preferred way forward?

--
Peter

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I agree, but I'd never have seen this as unwarranted or unbalanced
critics. I'm ok with it, and it spells less trouble for the pending
proposal too, as I've seen explicit interest from core developers to not
only accept AnnouncerPlugin code in Trac core, but hope to get more
people involved. I got, that they're really open-minded, just watching
out for best possible contributions.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCkOUMACgkQ31DJeiZFuHdcdACgpKgtGkLyjvIHdjQKVIAYjdnh
O8kAoILmn2bnyU5yYSYR3Gyf5h4ntVA0
=6UDv
-----END PGP SIGNATURE-----

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.11.2012 22:23, RjOllos wrote:
> On Wednesday, November 14, 2012 1:10:26 PM UTC-8, Remy Blank wrote:
>
> It's not that we *need* a rework, but since there was a proposal for
> integrating the AnnouncerPlugin, it was difficult to find motivation
> for
> fixing the existing system, as it would have been wasted effort.
>
> The proposal didn't materialize, and if there's no plan to revive it in
> the near future, it may make sense to go back to the current system and
> improve it.
>
>
> I think that Steffen and I would both like to revive the proposal, but I
> also think there is value in addressing some of the more undesirable
> behavior with the existing notification system, such as #2311, in the
> meantime.

Indeed. In fact, I meant to have already answered that open question by
my latest comments to some notification tickets. And IMHO we've already
made some progress.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCkQGUACgkQ31DJeiZFuHed0QCdE8NE2VZjVdOELAnszTkaGgLK
x7gAoOfz9gnUEvLZqYuLo5Bg+/lINUKK
=5tAe
-----END PGP SIGNATURE-----

[Brettschneider Falk]

RjOllos wrote:
> You will probably have better luck switching to the AnnouncerPlugin

Is it safe to use the latest SVN revision of AnnouncerPlugin? Because I've seen many commits these days, and I don't want to svn-checkout something unfinished.

Can AnnouncerPlugin provide similar notification behavior like Trac after the switch to that plugin (except my wish for previous updaters)? I don't want to confuse people here used to the current system.

[Ryan Ollos]

On Wed, Nov 14, 2012 at 11:39 PM, Brettschneider Falk <fbretts...@baumer.com> wrote:

> Is it safe to use the latest SVN revision of AnnouncerPlugin? Because I've seen many commits these days, and I don't want to svn-checkout something unfinished.

I would suggest you avoid using AnnouncerPlugin trunk in production for at least a few more weeks or months. I think the 0.11 (1) branch is much more stabl. Let's see what hasienda has to say.

 

Can AnnouncerPlugin provide similar notification behavior like Trac after the switch to that plugin (except my wish for previous updaters)? I don't want to confuse people here used to the current system.

I think the notification behavior will be very similar if you leave the defaults.

I did some brief testing, and it looks like we don't yet have the behavior you want (2). It looks like we'll need to add a rule with description "notify me when a ticket I updated is modified". I'll defer again to hasienda for a final verdict on this one, since I haven't worked with that part of the code much yet.

(1) http://trac-hacks.org/browser/announcerplugin/0.11 

(2)

[Brettschneider Falk]

Ryan Ollos wrote:
> and it looks like we don't yet have the behavior you want (2). It looks like we'll need to add a rule with description "notify me when a ticket I updated is modified".

Situation here is: a ticket passes several people one by one, by setting the current one as owner for a certain time. They can also write comments. But when the ticket has passed them, they don't want to get emails at all from that ticket anymore, only a moderator should.

Please, consider this if you start coding.

[RjOllos]

On Thursday, November 15, 2012 12:22:09 AM UTC-8, F@lk wrote:

Ryan Ollos wrote:
> and it looks like we don't yet have the behavior you want (2). It looks like we'll need to add a rule with description "notify me when a ticket I updated is modified".

Situation here is: a ticket passes several people one by one, by setting the current one as owner for a certain time. They can also write comments. But when the ticket has passed them, they don't want to get emails at all from that ticket anymore, only a moderator should.

Please, consider this if you start coding.

Captured some thoughts in this ticket: http://trac-hacks.org/ticket/10622 

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.11.2012 23:59, Peter Suter wrote:
> On 14.11.2012 20:53, Steffen Hoffmann wrote:
>> I know of Peter even asking about need for
>> support to do things on the AnnouncerPlugin to TracNotification effort,
>> but this happened some months ago.
>
> (15 months!?)

Really? I didn't look it up by now. Amazing, how time passed by.
However, my note on your request meant, that I've been sorry for a
possibly missed chance. Even better, that you're obviously still
interested in working with notification code.

> As Remy hinted at, the existence of AnnouncerPlugin and the integration
> proposal seems to paralyse development on TracNotification.
> Improving the existing system is not only wasted effort, it also makes
> replacing it harder and less urgent. So improving the current system is
> counter-productive if your real goal is integrating Announcer. :-/
>
> To me it seems really unfortunate that Announcer and TracNotification
> are so separate, incompatible, and (until recently) kind of dead. So a
> few weeks ago I started working again on a more concrete, piece-by-piece
> integration proposal. This has been put on hold for now, also because I
> noticed you heavily hacking on Announcer again!

Incompatible? Dunno, but I remember the sentence from the
AnnouncerPlugin wiki page, that for moving from TracNotification to
Announcer one may rename [notification] to [announcer] and go from
there. So it was meant with some compatibility in mind, at least
initially. I've not done a side-by-side feature and option comparison by
now, although this may be required for success of the replacement proposal.

> But since this topic is coming up now, here's a short overview of my idea:
>
> 1) Deprecate the old "high-level" system, don't heavily change or
> integrate it with new functionality. But keep the "low-level" code and
> configuration.
>
> 2) Dissect Announcer into topical parts. So far I identified:
> * Extension API for Mail/Distribion
> * Subscription DB & extension API, and "old" ticket subscriptions
> * Modular preference pages
> * New ticket subscriptions (Joinable ticket groups and components)
> * Permission filters
> * HTML emails
> * Wiki notifications
> * Attachment notifications
> * Watchable resources
> * Background delivery thread
> * SMTP-over-SSL
> * GPG encryption
>
> 3) Start integrating one of these and see how that is going.

Interesting approach.

> (Some of those parts could/should possibly remain plugins forever.)

So AnnouncerPlugin would be reduced to stuff, that lives in
announcer/opt now.

> But as I said, that was before you revived work on AnnouncerPlugin.
>
> What would be your preferred way forward?

I meant to bring Announcer into good shape, that would qualify for
inclusion, after current options and critical parts of the
TracNotification API had been mirrored.

Your suggestion to patch essential parts of current Announcer
infrastructure into existing TracNotification looks like a valid
alternative.

Certainly
* multiple transport options
* subscription model
* flexible user preferences
are the core of Announcer. For watching individual resources
WatchlistPlugin may actually be a better candidate. At least I've been
looking for a way to rather integrate/replace that part in Announcer
with WatchlistPlugin integration, because it's maintainer did a a good
job on the web-UI that I didn't want to re-invent.

Finally crypto functionality for notification is actually rather high on
my list, because I need that. But this will be totally reworked and
based on CryptoPlugin infrastructure. I'm sure, that especially this
code should change into a decorator (provided we'll make decorators
ordered extensions) and will remain in a plugin, because it's still far
from common stuff and real-world applications rarely care for privacy
and true confidentiality.

I know, this sounds odd, even more in business context, but I know that
most statements about data protection are vapor when it comes to
practical execution. Security comes at a price, that even many
businesses are not willing to pay today. So only very security
conscientious folks do signing and encryption on a regular base. With
ease of use this may change over time. Or with more privacy breaches, or
a combination of both. At least I'll contribute code to make this happen
for Trac applications, as far as users and admins will care.

I'm not determined about the best approach for the aforementioned
Announcer proposal yet. Actually I'm looking forward to reactions from
other developers about their view and vision for bringing in Announcer
features and more to Trac.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCn7wUACgkQ31DJeiZFuHdA8wCgxtiEGfndFGlBoNd7lTznjffR
Vy4AoOipkIzBoi4xTcP6lRtSNdk8cjwe
=cUVR
-----END PGP SIGNATURE-----

[Peter Suter]

On 17.11.2012 21:09, Steffen Hoffmann wrote:
>> (15 months!?)
>
> Really? I didn't look it up by now. Amazing, how time passed by.

Yes, I was surprised too. :)

> Incompatible? Dunno, but I remember the sentence from the
> AnnouncerPlugin wiki page, that for moving from TracNotification to
> Announcer one may rename [notification] to [announcer] and go from
> there. So it was meant with some compatibility in mind, at least
> initially. I've not done a side-by-side feature and option comparison by
> now, although this may be required for success of the replacement proposal.

I meant incompatible as in you can't use them both and automatically get
the best of both worlds. (While TracNotification has not changed a lot
there have been a few additions that I think are not yet in Announcer
e.g. batch notifications.) I'm not sure if one could use both at the
same time (e.g. because you use one plugin that sends announcements and
one that sends core notifications.)

>> But since this topic is coming up now, here's a short overview of my idea:

>> ...
> Interesting approach.

I've started writing up some more details as a proposal:
http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedNotification

> So AnnouncerPlugin would be reduced to stuff, that lives in
> announcer/opt now.

Basically, yes. I assume e.g. XMPP would stay in AnnouncerPlugin as
well. But even things like wiki notifications and html emails (while
really nice to have) would not be that important to transition into
core. The important thing would be that administrators can easily add
these features by installing AnnouncerPlugin without having to switch to
an entirely new system.

> Certainly
> * multiple transport options
> * subscription model
> * flexible user preferences
> are the core of Announcer.

Yes, and this core to me also seems quite mature. I really appreciate
that you want to bring the entire plugin into good shape. Just getting
the above into Trac seems almost too important to wait though.

> Finally crypto functionality [...]
> [...] will remain in a plugin, because it's still far

> from common stuff and real-world applications rarely care for privacy
> and true confidentiality.

Agree! I wondered if a new ICryptographyProvider extension point would
be needed for that, but using a decorator sounds like a good idea!

> I'm not determined about the best approach for the aforementioned
> Announcer proposal yet. Actually I'm looking forward to reactions from
> other developers about their view and vision for bringing in Announcer
> features and more to Trac.

Same here. Let's Cc trac-dev mailing list...

--
Peter

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15.11.2012 09:00, Ryan Ollos wrote:
> On Wed, Nov 14, 2012 at 11:39 PM, Brettschneider Falk
> <fbretts...@baumer.com <mailto:fbretts...@baumer.com>> wrote:
>
> > Is it safe to use the latest SVN revision of AnnouncerPlugin?
> Because I've seen many commits these days, and I don't want to
> svn-checkout something unfinished.
>
>
> I would suggest you avoid using AnnouncerPlugin trunk in production for
> at least a few more weeks or months. I think the 0.11 (1) branch is much
> more stabl. Let's see what hasienda has to say.

Sure. My recent Announcer changeset comments tell you pretty much the
same. I have the old announcer-0.12.1 with some patches in production,
but that limits it to 0.12 and early versions of 0.13dev before the
minor db API changes that are the root cause for the `AttributeError` in
this plugin's db schema version check. Btw, the same issue has been
reported for other plugins as well, i.e. TagsPlugin.

> Can AnnouncerPlugin provide similar notification behavior like Trac
> after the switch to that plugin (except my wish for previous
> updaters)? I don't want to confuse people here used to the current
> system.
>
>
> I think the notification behavior will be very similar if you leave the
> defaults.

Me too.

> I did some brief testing, and it looks like we don't yet have the
> behavior you want (2). It looks like we'll need to add a rule with
> description "notify me when a ticket I updated is modified". I'll defer
> again to hasienda for a final verdict on this one, since I haven't
> worked with that part of the code much yet.

Hm, you're certainly right about that. OTOH this type of implicit
subscription is a rather subtle one, that may be even look accidental to
some less experienced users, so I doubt, that this shortcoming would
become a blocker, if someone attempted a TracNotification --> Announcer
migration. Even more as I found it works not as reliable on t.h.o (near
Trac trunk, past 1.0 now) compared to t-h.o (still at ancient Trac
0.10.6dev).

Hope, this question even gets obsoleted by progress on the TracAnnouncer
proposal.

Steffen Hoffmann

[1] http://trac.edgewall.org/wiki/TracDev/Proposals/Announcer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCoDzoACgkQ31DJeiZFuHeMBgCgxZZztOxDhHm1CCdCGMKz/Nsu
Zx0AoNm499Rmj4WZZ25aNVakss2ignxq
=x51u
-----END PGP SIGNATURE-----

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15.11.2012 09:21, Brettschneider Falk wrote:
> Ryan Ollos wrote:
>> and it looks like we don't yet have the behavior you want (2). It
>> looks like we'll need to add a rule with description "notify me
>> when a ticket I updated is modified".
>
> Situation here is: a ticket passes several people one by one, by
> setting the current one as owner for a certain time. They can also
> write comments. But when the ticket has passed them, they don't want
> to get emails at all from that ticket anymore, only a moderator
> should.

Announcer has dedicated ticket owner notification
(TicketOwnerSubscriber: "notify me when a ticket that I own is created
or modified"), so no need for the suggested rule in your use case, if I
understand it correctly. Note that we recently added code to notify the
previous ticket owner on re-assignment (one last time) [1], while this
rather important demand is unresolved for TracNotification yet [2], but
recently got proposed patches.

Steffen Hoffmann


[1] http://trac-hacks.org/changeset/12333
[2] http://trac.edgewall.org/ticket/2311

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlCoE6AACgkQ31DJeiZFuHfwbwCgujWjEyDIl3NyB1aLD9aawHEF
/y8An2Rt5Mng+ycC3pHf/oVKM4cRDY0G
=nvjU
-----END PGP SIGNATURE-----

[Franz]

Hi,

I haven't read all your conversation, but I want to give my 2 cents. It would be great if the notification system of Trac would be improved - thank you for your effort to get it into Trac Core!

In our company a periodically sent report is an important feature (esp. for managers and project leaders). I have written a plugin for that: http://trac-hacks.org/wiki/MailPlugin. It would be great if you take a periodically sent report in consideration of the advanced notification (see also AnnouncerPlugin-ticket http://trac-hacks.org/ticket/8802).

Best regards,
Franz