> From: [email protected] On Behalf Of Eli Carter > Sent: Monday, April 23, 2007 12:10 PM
> > On Monday 23 April 2007, Puetz Kevin A wrote: > > ITicketActionController.get_ticket_changes gets to return a string > > describing side-effects that is shown in the ticket's preview, but > > when the change is actually made > (trac.ticket.web_ui._do_save) nothing > > is recorded in the ticket's change history. IMO it would be > helpful to > > record the side-effect description in ticket_change too, as well as > > any field changes. > > If you want to have something changed in the ticket, that > needs to be handled in the results from get_ticket_changes(). > > But the side effects should not be recorded like this. For > example, "email me a copy of this ticket" is not something > you want to have modify the ticket, but you will want a "A > copy of this ticket will be emailed to <address>" in the preview. Hmm, I can see that. Yet some sorts of side-effects do seem like they should be recorded. I'm thinking of something like "fix merged to branch <x> [changeset]", or a "request code review" action provided by something like the trac-hacks PeerReviewPlugin (if it weren't defunct, of course) that added a link to the relevant review notes in the history. Perhaps apply_ticket_side_effects should also return a description, which *is* recorded (if non-empty of course), so that it's up to the plugin? I suppose one could also just munge the comment field in get_ticket_changes(); the examples that came to mind are all basically boilerplate comments marking some external process, where I want to use an action to provide form elements and remind people what to include. Mixing the boilerplate notes with the user's free-form comments seems ugly to me, but it would probably work OK. > > Additionally, the ITicketChangeListener is called before the > > side-effects have been applied; this is not likely to cause many > > issues in practice, but it seems wrong in principle. > > Hmm. I see what you're saying here, but... the side-effects > are not supposed to change things that the > ITicketChangeListener is listening for, except delete/create. I agree with that, and that's why I didn't really think it would be a problem in practice. This didn't actually bite me; I just noticed it in passing. It seems like less surprising behavior to reorder it though. > Comments? > > Eli --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
