On Wed, Oct 23, 2013 at 10:47 AM, Gary Martin <[email protected]>wrote:

> On 23/10/13 12:51, Saint Germain wrote:
>
>> Hello,
>>
>> I would like to know what is the current status of BEP-0010
>> implementation.
>> It seems that with this changeset:
>> https://issues.apache.org/bloodhound/changeset/1517797
>> We have Alternative 1 of BEP-0010 in Bloodhound ?
>> How do we get the scoped ID from a ticket. ?
>>
>> Is there also a change in how TracLinks work ?
>> Following the same idea, I would like to refer to a ticket with
>> product-#number instead just a global #number.
>>
>> Thanks
>>
>
>

 I was under the impression that the scoped forms that should currently
> work would be (at least?):



  * product:PRE:ticket:123

 * PRE-123
>

There's also PRE->ticket:123 . See product_*.txt test cases [1]_



> The #123 links will, at least for now work through the implied scope and
> it will no longer be guaranteed to be unique globally so that you can have
> both P-123 and Q-123 existing simultaneously.
>

yes , that's right ...


>
> I suspect that we have not yet got an implementation for a short form for
> other scoped links.


yes , for reports ... see test cases in [1]_



> A generic PRE-[link] would be nice to have if possible which, to help
> users migrating from trac, might make PRE-#123 make a bit of sense and
> would also give us PRE-{1}, PRE-milestone:ms1, PRE-r123, PRE-[123] and all
> kinds of other links that I can't bring to mind immediately.
>

That's PRE->... short link form . See [1]_


>
> I think that Joe has suggested that #PRE-123 would be a good form in the
> case of tickets.


-
this will clash with existing plugin parsing hashtags as tags


> We could use that to give us the option of subverting # to use to denote
> products when the string immediately following is not numeric.


product:"PRE WITH SPACES:ticket:6"


> I don't think that is strictly necessary but it is interesting as it would
> enable us to refer to an entire product as #PRE if we wished.
>

-
this will clash with existing hashtags parsers once again ...

-- 
Regards,

Olemis - @olemislc

Reply via email to