On Fri, Oct 26, 2012 at 9:36 PM, Olemis Lang <[email protected]> wrote:
> On 10/26/12, Ryan Ollos <[email protected]> wrote: > > On Fri, Oct 26, 2012 at 1:41 AM, Jure Žitnik <[email protected]> wrote: > > > >> I think we need a consistent 'notification strategy' which is basically > >> deciding whether changes to structures related to tickets (products, > >> milestones...) actually result in ticket notifications or not. > >> > > > > This has been on my mind while working on some ticket, particular: > > http://trac.edgewall.org/ticket/4582#comment:6 > > I've been thinking that I might open a dedicated ticket in the Trac core > > after #4582 and #5658 are resolved to deal with the inconsistencies of > when > > notifications are sent. > > > > What you are doing over there seems to be exactly like batch > modifications . isn't it better to reuse batch modification code in > query module and make the whole thing to look exactly like if logged > in user had selected target tickets , set product=new_product and > comment field set to something like «Renaming product XXX to YYY »? > > Besides there is a way to control whether notifications are sent or > not . Take a look at the functions in TicketRPC class [1]_ > > IMO _update_relations is not ok , and that's been my opinion since > long time ago . The right way to go should be to use (immutable) > product prefix rather than its name for all these sort of relations , > as stated in #110 . Modifying product prefix would be a more unlikely > operation thus scripts for admin tasks would be ok to handle this . > Nonetheless product names are more pretty and currently element value > is always the same as element text. > > Q: > > - Is there any trac hack to include id & value in select ticket fields ? > > .. [1] TicketRPC exported methods - from line 68 down to line 325 > ( > http://trac-hacks.org/browser/xmlrpcplugin/trunk/tracrpc/ticket.py) > > -- > Regards, > > Olemis. > > Blog ES: http://simelo-es.blogspot.com/ > Blog EN: http://simelo-en.blogspot.com/ > > Featured article: > Not sure why we would have to have ticket notification change events if I rename a product from "My product" to "MyProduct". The same goes for versions, milestones and the like. If the BH/trac needs them internally I am sure there are ways around it, as a user I surely don't need separate email for each affected ticket, just the one saying that product or milestone or whatever has changed would be enough. Peter
