bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Datamodel and data consistency
Date Fri, 26 Oct 2012 19:36:01 GMT
On 10/26/12, Ryan Ollos <> wrote:
> On Fri, Oct 26, 2012 at 1:41 AM, Jure Žitnik <> 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:
> 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.


  - Is there any trac hack to include id & value in select ticket fields ?

.. [1] TicketRPC exported methods - from line 68 down to line 325



Blog ES:
Blog EN:

Featured article:

View raw message