Mr. Meitar Moscovitz wrote:
> On Aug 22, 2008, at 10:40 AM, Remy Blank wrote:
>
>> Mr. Meitar Moscovitz wrote:
>>> This creates a very loose concept of a "superticket" and a
>>> "subticket", but does not cause the software to enforce any kinds of
>>> dependencies or workflow on these tickets, which is what we want.
>>> Nevertheless, this is extremely useful because then traditional
>>> queries can reference "all subtickets" of a ticket simply by using a
>>> query like one in the following example (which shows subtickets for
>>> ticket:13):
>>>
>>> [[TicketQuery(kewords~=#13)]]
>>>
>>> To any supertickets in our projects, we typically add this
>>> TicketQuery
>>> macro at the end of the ticket description so that the ticket
>>> description itself contains a listing of all its subtickets.
>> This is a very interesting idea, thanks for sharing!
>
> I'm glad others find it interesting. :)
>
>> The only drawback I
>> see is that your query "keywords~=#13" will match all subtickets of
>> #13,
>> #130, #131, #132, ... which is probably not what you want.
>
> That's a good point, actually, and no, that's not what we want. I
> think we haven't run into this problem yet because we've simply begun
> using this technique mid-way through and we were already at 3-digit
> ticket numbers. So for instance, when we do
> [[TicketQuery(keywords~=#267)]] it's much less likely that we'll run
> into that problem (until we hit ticket:2670 of course).
>
> To avoid this, I suppose it's possible to do a number of things to
> work around the issue (but I'm guessing here, not actually trying it
> out).
>
> 1. You can use the "ends with" operator and ensure that your
> "subticket keyword" (as described above) is at the end of the Keywords
> field. Thus:
> {{{
> [[TicketQuery(keywords$=#13)]]
> }}}
> Naturally, the downside to this option is that you (sort of)
> limit yourself to associating a ticket with a single superticket.
> 2. You use spaces (or some other character) around the subticket
> keyword and match those delimiters explicitly. Thus:
> {{{
> [[TicketQuery(keywords~= #13 )]]
> }}}
> or maybe you could use "T" for "ticket"
> {{{
> [[TicketQuery(keywords~=T#13T)]]
> }}}
> Of course, the downside with this approach is that the usability
> of entering such subticket keywords suffers.This was exactly how the 0.10 version of the plugin tried to work, just using some funky SQL to pull data from a semi-formatted text field. This didn't work well at all, hence the massive warning against using that iteration of the plugin. Using an actual table does mean there is an invariant relationship, but as long as people use the Trac API everything will stay in sync. If you pulled out the depgraph support, basically all you would have is a system to keep the mastertickets table in sync with the ticket fields, updating wherever needed. --Noah
signature.asc
Description: OpenPGP digital signature
