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.
> A new match operator for "contains the word ..." would be useful.
>
> -- Remy
That's certainly another option. It's actually probably the best
option, really.
I have never looked at Trac's source code so I don't know how it
implements its TracQuery "sublanguage." Taking a guess from looking at
the operators it uses, however, it does look like it's simply regex-
based and depending on the regex engine Trac uses it should be trivial
to implement a word-boundary-matching operator such as the one you
describe.
In fact, do you know if implementing this is something that would,
indeed, be "relatively easy"? If so, I think I might have a go at
implementing it myself since my team uses this whole "subticket/
superticket" concept rather extensively now (and I'd like to avoid
just the situation you describe). I'd be happy to supply a patch, too,
if it's of interest to others--I just don't want to start down this
path if other, more experienced Trac folks think this is a waste of
effort or would be biting off more than I could chew as a green Trac
developer.
Anyway, thanks again for the (very) useful feedback!
Cheers,
--
-Meitar Moscovitz
Personal: http://maymay.net
Professional: http://MeitarMoscovitz.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
