What is a good way to modify tickets at the time they are created?

[RjOllos]

I was doing some work recently on the DefaultCcPlugin, which adds a CC field to Version, and adds this CC list to the ticket /after/ it is created (1). The undesirable thing that happens right now is that a comment is added to the ticket, because TicketModel.save_changes is called in the method that implements ITicketChangeListener.ticket_created.

There is the unimplemented ITicketManipulator, which seems ideal for this (2). However, since that isn't yet functional, should I just execute SQL in the method that implements ITicketChangeListener.ticket_created (3)? Or is there a better way?

(1) http://trac-hacks.org/browser/defaultccplugin/trunk/defaultcc/main.py?marks=40-43#L34
(2) http://trac.edgewall.org/browser/trunk/trac/ticket/api.py?marks=129-131#L126
(3) http://trac.edgewall.org/browser/trunk/trac/ticket/api.py?marks=112-113#L108

[Peter Suter]

On 21.07.2012 05:34, RjOllos wrote:
> There is the unimplemented ITicketManipulator, which seems ideal for
> this (2). However, since that isn't yet functional,

I think only the `prepare_ticket` is not called, but you can use
`validate_ticket` for this.

This was discussed a bit in #10125. An example was given there:
http://trac.edgewall.org/ticket/10125#comment:4

I think this approach is also used in:
http://trac-hacks.org/svn/epochfieldplugin/0.12/epochfield/filter.py
http://trac-hacks.org/svn/trachoursplugin/trunk/trachours/ticket.py
http://trac-hacks.org/svn/trachoursplugin/trunk/trachours/hours.py
and probably others.

[Peter Suter]

On 21.07.2012 05:34, RjOllos wrote:

> There is the unimplemented ITicketManipulator, which seems ideal for
> this (2). However, since that isn't yet functional,

I also just now created the documentation wiki page [1] for that
interface; maybe that helps / would have helped. Or maybe you know or
notice more helpful information that should be mentioned there.

[1]
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.ticket.api.ITicketManipulator

[Steffen Hoffmann]

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

On 21.07.2012 08:46, wrote Peter Suter:
> This was discussed a bit in #10125. An example was given there:
> http://trac.edgewall.org/ticket/10125#comment:4

Thank you for this hint. Just what I needed for re-thinking and cleaning
my plugin design these days.

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

iEUEARECAAYFAlAKnfAACgkQ31DJeiZFuHfMWgCgg0cjKMpd3FnHuI0KNGa2zx0r
8gcAmOgvQnOQG9MRMID+MuZ3FQX//iA=
=Uy9H
-----END PGP SIGNATURE-----

[RjOllos]

On Saturday, July 21, 2012 6:49:04 AM UTC-4, Peter Suter wrote:

I also just now created the documentation wiki page [1] for that
interface; maybe that helps / would have helped. Or maybe you know or
notice more helpful information that should be mentioned there.

Thanks, the documentation you've been adding lately has been very helpful. Looking at your new documentation for IAttachmentManipulator last night is what reminded me to ask this question after it's been on my mind for a while.

Do you know if there is any intention to ever call prepare_ticket, elevating it from dummy status? I couldn't find a ticket for this.

[Peter Suter]

On 21.07.2012 20:55, RjOllos wrote:
> Do you know if there is any intention to ever call prepare_ticket,
> elevating it from dummy status? I couldn't find a ticket for this.

I have no evidence for (or against) that. (Or I would have added it to
the docs :)

Do you have a use case for it? A clear idea of when it should be called?

[RjOllos]

On Saturday, July 21, 2012 3:15:52 PM UTC-4, Peter Suter wrote:

Do you have a use case for it? A clear idea of when it should be called?

Nothing in particular yet. I just imagined a better overall design where the ticket properties were modified in `prepare_ticket` and `validate_ticket` only accepted/rejected the ticket, with no side-effects.

[RjOllos]

On Friday, July 20, 2012 11:34:41 PM UTC-4, RjOllos wrote:

I was doing some work recently on the DefaultCcPlugin, which adds a CC field to Version

I should have said, Component, not Version. 

[RjOllos]

Changes to the DefaultCcPlugin implemented in (1) per Peter Suter's suggestions in this thread.

(1) http://trac-hacks.org/changeset/11747