You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@bloodhound.apache.org by Apache Bloodhound <bl...@incubator.apache.org> on 2013/02/14 18:34:41 UTC
[Apache Bloodhound] #390: Product wiki syntax
#390: Product wiki syntax
---------------------+---------------
Reporter: olemis | Owner:
Type: task | Status: new
Priority: major | Version:
Resolution: |
---------------------+---------------
Add TracLinks for products and wiki syntax for product resources .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Olemis Lang <ol...@gmail.com>.
On 3/5/13, Gary Martin <ga...@wandisco.com> wrote:
> On 04/03/13 22:39, Olemis Lang wrote:
>> even if we don't choose sep = '-' it seems it may be matched
>>
>> so far I have discarded these chars as prefixes
>>
>> / collisions with relative wiki page refs in wiki context
>> - has a major ambiguity when it comes to expanding raw-attachment and
>> similar TracLinks namespace
>> : TracLinks meta-char , obviously out
>> . collisions with relative wiki
>>
>> I'm starting to think that we should be using one of ~ >
>>
>> 1. prefix~#123
>> 2. prefix>#123
>>
>> ... or a combination of the former e.g.
>>
>> 3. prefix->#123
>>
>> I think I'd rather prefer 1 or 3 . In the first version I'll implement
>> (1)
>
> Well, I have considered those and I might compromise (I prefer '>') but...
>
ok . I'll use that . No problem .
;)
> The case of raw-attachment is a very good point. However, it is possible
> to get around it and it also has a particular major advantage if we ever
> get people to defect from jira. In order to achieve that I would be
> prepared to drop the requirement to be able to use the short form for
> anything other but tickets. In particular PREFIX-123 would be the
> important case.
>
+1
> If we are interested in more, it would be possible to get away with '-'
> under more conditions by specifying only uppercase namespaces are
> allowed or making by deciding how a clash with other link resolvers will
> be resolved. It should be noted that '-' is a problem for
> 'raw-attachment' because of 'attachment'.
>
> It might be annoying for the raw product that you are unable to refer to
> attachments in that form but from within the product I still expect
> users to be able to drop the prefix and externally there is still the
> product:raw:attachment: form.
>
The fact is that external link resolvers (i.e. wiki syntax extensions)
will be matched first , so afaict the result of making both work
side-by-side will be the impossibility of using raw-attachment prefix
at all , i.e. no fallback possible
--
Regards,
Olemis.
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Gary Martin <ga...@wandisco.com>.
On 04/03/13 22:39, Olemis Lang wrote:
> even if we don't choose sep = '-' it seems it may be matched
>
> so far I have discarded these chars as prefixes
>
> / collisions with relative wiki page refs in wiki context
> - has a major ambiguity when it comes to expanding raw-attachment and
> similar TracLinks namespace
> : TracLinks meta-char , obviously out
> . collisions with relative wiki
>
> I'm starting to think that we should be using one of ~ >
>
> 1. prefix~#123
> 2. prefix>#123
>
> ... or a combination of the former e.g.
>
> 3. prefix->#123
>
> I think I'd rather prefer 1 or 3 . In the first version I'll implement (1)
Well, I have considered those and I might compromise (I prefer '>') but...
The case of raw-attachment is a very good point. However, it is possible
to get around it and it also has a particular major advantage if we ever
get people to defect from jira. In order to achieve that I would be
prepared to drop the requirement to be able to use the short form for
anything other but tickets. In particular PREFIX-123 would be the
important case.
If we are interested in more, it would be possible to get away with '-'
under more conditions by specifying only uppercase namespaces are
allowed or making by deciding how a clash with other link resolvers will
be resolved. It should be noted that '-' is a problem for
'raw-attachment' because of 'attachment'.
It might be annoying for the raw product that you are unable to refer to
attachments in that form but from within the product I still expect
users to be able to drop the prefix and externally there is still the
product:raw:attachment: form.
Cheers,
Gary
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Olemis Lang <ol...@gmail.com>.
I have been tempted to write a long reply , but I won't . I'll just
reply quicly between the lines . Product wiki syntax is almost ready
and working . I'm just writing test cases to cover all forms and deal
with some exotic . I propose we focus our efforts on discussing about
how to improve what I'll submit in the next few days , once we all be
aware of the limitations and technical challenges solved and pending
;)
BTW , After getting my hands dirty I realized that *many* of the
previous suggestions mentioned before are not even valid TracLinks
expressions . That will shape the form of the final solution though .
On 3/4/13, Gary Martin <ga...@wandisco.com> wrote:
> On 21/02/13 10:14, Andrej Golcov wrote:
>> Regarding prefixing tickets with "#".
>> We still have to support #123 notation for wiki links inside the
>> product. IMHO, introducing non-relative wiki links for tickets without
>> # (e.g. bh/123) can be user confusing. My +1 to leave # for full
>> path tickt links, e.g. #produc<delimeter>productid
>>
>> Regards, Andrej
>
> In case it isn't spotted from another related thread, I believe that
> when using # in the link, it should always appear after any product
> specification.
+1
> The forms for the links will therefore be
>
> * <reslink>
> * product:<prefix>:<reslink>
> * <prefix><sep><reslink>
>
+1
> where <reslink> is any currently valid resource link (#<id>,
> ticket:<id>, milestone:<id>, wiki:<id> etc).
+1 ... though ... ;)
> In addition, specifically
> for tickets and wiki pages we will allow:
>
> * <prefix><sep><id>
>
for tickets +1 . for wiki pages I'm not sure
> as long as the wiki page matches the current rules for automatically
> being interpreted as wikipage links. On this basis we will be able to
> match the the form of jira tickets if we choose <sep> = '-'
even if we don't choose sep = '-' it seems it may be matched
so far I have discarded these chars as prefixes
/ collisions with relative wiki page refs in wiki context
- has a major ambiguity when it comes to expanding raw-attachment and
similar TracLinks namespace
: TracLinks meta-char , obviously out
. collisions with relative wiki
I'm starting to think that we should be using one of ~ >
1. prefix~#123
2. prefix>#123
... or a combination of the former e.g.
3. prefix->#123
I think I'd rather prefer 1 or 3 . In the first version I'll implement (1)
> and maybe we
> should just do so. Some of the things to consider for that are:
>
> * false matches on 'var-N' which would either have to be escaped by
> one of the standard means or just written as 'var - N'
+1
> * potential ambiguity if '-' is allowed in the prefix itself,
in any case only alphanumeric (inlcuding unicode) chars will be
supported in short forms .
> which
> might suggest we should avoid the issue by disallowing products
> being set up with '-' in the prefix; existing products with this
> will work with 'product:<prefix>:<reslink>' syntax of course.
>
Other kinds of prefixes will make use of link resolvers only .
> Does anyone spot any additional problems or have any objections to this?
>
let the test suite talk , please be patient
;)
--
Regards,
Olemis.
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Gary Martin <ga...@wandisco.com>.
On 21/02/13 10:14, Andrej Golcov wrote:
> Regarding prefixing tickets with "#".
> We still have to support #123 notation for wiki links inside the
> product. IMHO, introducing non-relative wiki links for tickets without
> # (e.g. bh/123) can be user confusing. My +1 to leave # for full
> path tickt links, e.g. #produc<delimeter>productid
>
> Regards, Andrej
In case it isn't spotted from another related thread, I believe that
when using # in the link, it should always appear after any product
specification. The forms for the links will therefore be
* <reslink>
* product:<prefix>:<reslink>
* <prefix><sep><reslink>
where <reslink> is any currently valid resource link (#<id>,
ticket:<id>, milestone:<id>, wiki:<id> etc). In addition, specifically
for tickets and wiki pages we will allow:
* <prefix><sep><id>
as long as the wiki page matches the current rules for automatically
being interpreted as wikipage links. On this basis we will be able to
match the the form of jira tickets if we choose <sep> = '-' and maybe we
should just do so. Some of the things to consider for that are:
* false matches on 'var-N' which would either have to be escaped by
one of the standard means or just written as 'var - N'
* potential ambiguity if '-' is allowed in the prefix itself, which
might suggest we should avoid the issue by disallowing products
being set up with '-' in the prefix; existing products with this
will work with 'product:<prefix>:<reslink>' syntax of course.
Does anyone spot any additional problems or have any objections to this?
Cheers
Gary
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Andrej Golcov <an...@digiverse.si>.
Regarding prefixing tickets with "#".
We still have to support #123 notation for wiki links inside the
product. IMHO, introducing non-relative wiki links for tickets without
# (e.g. bh/123) can be user confusing. My +1 to leave # for full
path tickt links, e.g. #produc<delimeter>productid
Regards, Andrej
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Gary Martin <ga...@wandisco.com>.
On 20/02/13 18:41, Olemis Lang wrote:
> On 2/20/13, Olemis Lang <ol...@gmail.com> wrote:
>> On 2/20/13, Gary Martin <ga...@wandisco.com> wrote:
>>> On 14/02/13 17:34, Apache Bloodhound wrote:
>>>> #390: Product wiki syntax
> [...]
>>> My preference is for '/' at this point - the only potential clash that
>>> springs to mind is with Wiki/Pages but those seem to require some
>>> specific uppercase rules.
>>>
>>> Are there any other problems others can spot?
>>>
>> AFAICR bh/whateever within a wiki page context will be expanded to
>> relative page . I guess hyphens and/or dots are less problematic
>> (unless I'm missing something ;) .
>>
> jftr ... I'm mainly saying that this will be problematic with the long
> form e.g. [bh/milestone:m1 caption]
>
As far as I can tell, that will not be a problem. The only problem will
be for wiki pages when someone specifies in these forms:
Bh/WikiPage
Bh/Wikipage
both of which are currently already treated as wikipages. The first we
would want to be interpreted as a link to WikiPage in the Bh product.
Perhaps it is a little much to say that we only accept all uppercase or
all lowercase as the prefix.
Cheers,
Gary
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Olemis Lang <ol...@gmail.com>.
On 2/20/13, Olemis Lang <ol...@gmail.com> wrote:
> On 2/20/13, Gary Martin <ga...@wandisco.com> wrote:
>> On 14/02/13 17:34, Apache Bloodhound wrote:
>>> #390: Product wiki syntax
[...]
>>
>> My preference is for '/' at this point - the only potential clash that
>> springs to mind is with Wiki/Pages but those seem to require some
>> specific uppercase rules.
>>
>> Are there any other problems others can spot?
>>
>
> AFAICR bh/whateever within a wiki page context will be expanded to
> relative page . I guess hyphens and/or dots are less problematic
> (unless I'm missing something ;) .
>
jftr ... I'm mainly saying that this will be problematic with the long
form e.g. [bh/milestone:m1 caption]
--
Regards,
Olemis.
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Olemis Lang <ol...@gmail.com>.
On 2/20/13, Gary Martin <ga...@wandisco.com> wrote:
> On 14/02/13 17:34, Apache Bloodhound wrote:
>> #390: Product wiki syntax
>> ---------------------+---------------
>> Reporter: olemis | Owner:
>> Type: task | Status: new
>> Priority: major | Version:
>> Resolution: |
>> ---------------------+---------------
>> Add TracLinks for products and wiki syntax for product resources .
>>
>
[...]
>
> For consistency with the rest of the system we are almost certainly
> going to support product:prefix as a way of referring to a product as a
> whole. It would then seem reasonable to extend this to allow
> product:<prefix>:<resource> so for a prefix of bh we would have:
>
> product:bh -> link to the product
> product:bh:ticket:123 and product:bh:#123 -> links to ticket 123 in bh
> product:bh:milestone:m1 -> link to milestone m1 in bh
>
+1
This is consistent with my initial idea . I just didn't want to spend
time writing this and prioritize #355 i.e. TC conversion
> and so on. I would be happy to see this as a longhand form if this is
> seen as useful.
>
its a MUST as a last recourse for disambiguation .
[...]
> Before listing what these would look like for tickets, I would like to
> suggest that in the case of tickets, we could also drop the requirement
> to add a '#' to specify the ticket, this would force us to remove
> ambiguity for numeric wiki pages by requiring links like
> <prefix><sep>wiki:123, but I think that this is a small price to pay for
> brevity in ticket syntax.
IMO there's no need to drop it ... we can add numeric patterns rules
to consider them as ticket IDs by default .
> Therefore these appear to be the choices for
> representing #123 in product:bh in the shortest form:
>
> bh-123
> bh/123
> bh.123
> bh:123
>
> and here is the same for milestone m1 in bh:
>
> bh-milestone:m1
> bh/milestone:m1
> bh.milestone:m1
> bh:milestone:m1
>
> Each is likely to have their problems - the last case is interesting as
> it requires overloading InterTrac entries and could almost be emulated
> by users anyway if they prefer that form. There could also be clashes
> between defined InterTrac entries every so often though it might be
> possible to get around these problems.
-1 for : separator char
> The first form matches the jira
> names for tickets but we may have to question if hyphens should be
> allowed in a prefix and whether we want to deal with that.
>
> My preference is for '/' at this point - the only potential clash that
> springs to mind is with Wiki/Pages but those seem to require some
> specific uppercase rules.
>
> Are there any other problems others can spot?
>
AFAICR bh/whateever within a wiki page context will be expanded to
relative page . I guess hyphens and/or dots are less problematic
(unless I'm missing something ;) .
--
Regards,
Olemis.
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Gary Martin <ga...@wandisco.com>.
On 14/02/13 17:34, Apache Bloodhound wrote:
> #390: Product wiki syntax
> ---------------------+---------------
> Reporter: olemis | Owner:
> Type: task | Status: new
> Priority: major | Version:
> Resolution: |
> ---------------------+---------------
> Add TracLinks for products and wiki syntax for product resources .
>
I am not sure that we have proper guidance for the product wiki syntax
yet. I don't want to spend too long on this decision so here is a
quickish overview of a few choices. My preference is stated at the end.
For consistency with the rest of the system we are almost certainly
going to support product:prefix as a way of referring to a product as a
whole. It would then seem reasonable to extend this to allow
product:<prefix>:<resource> so for a prefix of bh we would have:
product:bh -> link to the product
product:bh:ticket:123 and product:bh:#123 -> links to ticket 123 in bh
product:bh:milestone:m1 -> link to milestone m1 in bh
and so on. I would be happy to see this as a longhand form if this is
seen as useful.
That syntax is a bit bulky and so I think we all expect some shorter
form, particularly for tickets so we basically want an additional syntax
of the form <prefix><sep><resource>. Some of the most obvious choices
for the separator appear to be: '-', '/', '.' and ':'.
Before listing what these would look like for tickets, I would like to
suggest that in the case of tickets, we could also drop the requirement
to add a '#' to specify the ticket, this would force us to remove
ambiguity for numeric wiki pages by requiring links like
<prefix><sep>wiki:123, but I think that this is a small price to pay for
brevity in ticket syntax. Therefore these appear to be the choices for
representing #123 in product:bh in the shortest form:
bh-123
bh/123
bh.123
bh:123
and here is the same for milestone m1 in bh:
bh-milestone:m1
bh/milestone:m1
bh.milestone:m1
bh:milestone:m1
Each is likely to have their problems - the last case is interesting as
it requires overloading InterTrac entries and could almost be emulated
by users anyway if they prefer that form. There could also be clashes
between defined InterTrac entries every so often though it might be
possible to get around these problems. The first form matches the jira
names for tickets but we may have to question if hyphens should be
allowed in a prefix and whether we want to deal with that.
My preference is for '/' at this point - the only potential clash that
springs to mind is with Wiki/Pages but those seem to require some
specific uppercase rules. Are there any other problems others can spot?
Cheers,
Gary
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by andrej):
> Is the search page not going to be available under a product url?
As far as I understand, we plan to have global search url with optional
product selector.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:9>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: closed
Priority: major | Milestone: Release 6
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: fixed | TracLinks
-------------------------+-------------------------------------------------
Changes (by rjollos):
* milestone: => Release 6
Comment:
Please correct if I've not set the milestone appropriately here.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:19>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Changes (by olemis):
* status: assigned => accepted
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:5>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: new
Priority: major | Milestone: Release 6
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Changes (by olemis):
* status: closed => new
* resolution: fixed =>
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:22>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: closed
Priority: major | Milestone: Release 6
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: fixed | TracLinks
-------------------------+-------------------------------------------------
Changes (by jure):
* status: assigned => closed
* resolution: => fixed
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:25>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: assigned
Priority: major | Milestone: Release 6
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Changes (by olemis):
* status: new => assigned
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:23>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: closed
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: fixed | TracLinks
-------------------------+-------------------------------------------------
Changes (by jure):
* status: review => closed
* resolution: => fixed
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:18>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: assigned
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Changes (by olemis):
* status: review => assigned
Comment:
sorry ... review => assigned
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:4>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
I'm proposing to new patches for #390 .
[attachment:t355_r1450181_trac_test_ticket_wikisyntax.diff:ticket:355 The
first one] is the continuation of the work made in #355 (reopened
accordingly) . It checks for ticket wiki syntax . OTOH
[attachment:t390_r1450181_product_wikisyntax.diff the second one]
implements product link resolver . Thatalso includes nested expressions
referencing product resources .
They have been built and tested against r1452271 and should be applied in
the following order :
{{{
#!sh
$ hg qapplied
t355/t355_r1452271_trac_test_ignore_subpkg_root.diff
t355/t355_r1452271_trac_test_ticket_wikisyntax.diff
t390/t390_r1452271_product_wikisyntax.diff
}}}
Observations :
- If you take a look at [http://pastebin.com/PSzv0eZd this test report]
including a relevant subset of the test suite affected by these
modifications
then you might notice that the only failed test cases are
* those for `TicketQuery` , maybe related to #434
(@jure @mathevzb could you please take a look ?)
* ... and a few more to check for a bizarre case (unicode chars , etc
...)
I'll deal with this one .
- I have improved built-in `WikiTestCase` class to introduce the notion
of
product testing environments, which may be useful to assert similar
conditions for both global and product envs by writing test code once
.
I'm hoping this will be used more often beyond this limited context
so that we make use of these in a consistent manner .
- The solution is smart when expanding nested (i.e. product: , global:)
TracLinks
expressions containing whitespaces . For instance the equivalent of
this link
`search:"foo bar"` will be `global:"search:foo bar"` or
`product:"PREFIX:search:foo bar"` instead of `global:"search:\"foo
bar\""` .
More examples in the test cases.
- I have been trying to stay consistent with established rules of
TracLinks expansion by removing product:prefix in some link labels
and keeping it under other circumstances . See samples test cases.
- ... nonetheless there is a notable case I'm not comfortable with.
See #433
- product::realm:id will not be parsed by the link resolver without
a few quotes , and thereby will not be supported . Scheduled in #435
- If expanded links consist of an outermost tag having `title`
attribute then nested links formatter (the heart of the whole
thing ;) will decorate the title automatically using `<global>`
or `[PREFIX]` depending on the context . See the test cases.
- ... this leaves attachment: fragments behind (see #436)
- I have started patches for enhanced ticket and report syntax ...
coming soon , please be patient .
- While working on product environments , models should be
automatically constrained to using product prefix . This is
also related to the duality in using both product
prefix column as well as custom field for tickets . See #437
- The solution should be smart enough to detect whether absolute or
relative href(s) should be used to generate URLs . Test cases
needed though (see #442)
- Some product-specific extensions to the environment API have been
developed (see #443)
- The solution puts rendering engine in the right permissions
context while expanding global: and product: links .
I wanted to share what I got sooner rather than later . Please review the
test cases for further details about how product: and global: TracLinks
namespaces are supposed to work . Suggest modifications accordingly .
There's another pending patch for custom wiki syntaxes . Nonetheless ,
after the comments I received today via the bloodhound-dev@i.a.o ML I'm
switching to another task . I'll come back on this once I finish those .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:6>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: review
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Changes (by olemis):
* status: accepted => review
* owner: olemis => jure
Comment:
I submitted [attachment:t390_r1450181_product_wikisyntax_report.diff
another patch] extending report compact syntax in the following ways
1. Retry `{ns 1}` links when `ns` is not an InterTrac prefix
2. `{product:PREFIX 1}` , `{product:PREFIX:1}`, `{global:1}`
2. `product:"PREFIX:{1}"` , `product:"PREFIX:{1}"`, `global:"{1}"` (<=
QUOTED ;)
3. `{PREFIX~1}` , `PREFIX~{1}` ... where `~` is product syntax delimiter
(see comment:)
{{{
#!sh
$ hg qapplied
t390/t390_r1453952_product_wikisyntax.diff
t390/t390_r1453952_product_ticket_jira.diff
t390/t390_r1453952_product_wikisyntax_nomatch.diff
t390/t390_r1453952_product_wikisyntax_compact.diff
t390/t390_r1450181_product_wikisyntax_report.diff
t434/t434_r1453952_product_ticketquery.diff
$ hg log -r qparent --template="[{svnrev}] - {desc}\n"
[1455129] - #429 - Multiproduct UI: Ticket page (modify ticket was not
working)
$ python setup.py test -m tests.wikisyntax
[...]
----------------------------------------------------------------------
Ran 222 tests in 52.724s
OK
}}}
IMO , this is all we need . If something is wrong or missing then feel
free to reopen this ticket , though I'll recommend to spawn another one
from this point .
PS: Later today you'll get a report of the full test suite . Until
yesterday it was quite green , the only exception being the case mentioned
in comment:14
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:16>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
Replying to [comment:9 andrej]:
> > Is the search page not going to be available under a product url?
> As far as I understand, we plan to have global search url with optional
product selector.
AFAICT this is just a matter of putting things in the right context , and
limit by default the scope of search results by applying product=PREFIX
constraint *if* running inside a product environment (i.e. `/products` URL
namespace ) *and* no other product value is explicitly provided by user .
Let's think of a potential deployment @ apache.org . I see no point in
searching for a term in Bloodhound product scope and get results from
whatever other sibling projects ... unless I make such explicit decision
e.g. in a similar way to Google sites (custom) search (o Search domain X |
o Search the web)
PS: BTW ... we should be dealing with this in #450
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:11>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: review
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Changes (by olemis):
* status: accepted => review
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:2>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: review
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by gjm):
Given that there did not appear to be a discussion on this anywhere, I
have put a quick analysis in this thread:
http://markmail.org/thread/df5skqhj3bu5gwah
Long story short, I suggest that for a short form we could use
{{{<prefix>/<resource>}}} with tickets in particular allowing us to drop
the {{{#}}} thus giving links like:
* bh/milestone:iteration1
* bh/123
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:3>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Changes (by olemis):
* owner: => olemis
* keywords: => product resource wiki syntax TracLinks
* status: new => accepted
* component: => multiproduct
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:1>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: review
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by jure):
t390_r1453952_product_wikisyntax.diff applied in r1455444
t390_r1453952_product_ticket_jira.diff applied in r1455452
t390_r1453952_product_wikisyntax_nomatch.diff applied in r1455454
t390_r1453952_product_wikisyntax_compact.diff applied in r1455457
t390_r1450181_product_wikisyntax_report.diff applied in r1455473
note: wikisyntax.diff had `from ImageStat import Stat` as the first line
in `multiproduct/env.py`. removed.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:17>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
Replying to [comment:7 andrej]:
> Replying to [comment:6 olemis]:
> [...]
> > - The solution is smart when expanding nested (i.e. product: ,
global:) TracLinks
> > expressions containing whitespaces . For instance the equivalent
of this link
> > `search:"foo bar"` will be `global:"search:foo bar"` or
> > `product:"PREFIX:search:foo bar"` instead of `global:"search:\"foo
bar\""` .
> > More examples in the test cases.
> Search is not resource and I suggest to have search always global. If
user want specify product, syntax may look like:
{{{search:?q=trac+link&product=xxx}}} similar to existing legacy search
syntax e.g.: {{{search:?q=trac+link&wiki=on}}}
If that's the case then the link resolver (i.e. bh search plugin) has to
provide the right syntax . Notice that such URLs are generated by
TracSearch link resolver rather than our plugin . The nested links
formatter does not tweak URLs in any especial way . That's a
responsibility of product environment's href . So if you choose global
path only then there are two observations :
1. what will users get on accessing `/product/PREFIX/search` ? HTTP 404
? Redirect ?
2. I'd suggest to make `/product/PREFIX/search` equivalent to
/search?q=whatever&product=xxx as long as no other explicit
constraint will override it .
3. tests make use of built-in search component not bh search .
4. the TracLinks are decoupled from URL handling and generation .
Developers are still free to do whatever is considered correct
by implementing `IWikiSyntaxProvider` and nested resources formatter
will
stay out of the way . If product-aware , it's your plugin hence your
decision ;)
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:12>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by gjm):
Replying to [comment:7 andrej]:
> Replying to [comment:6 olemis]:
> [...]
> > - The solution is smart when expanding nested (i.e. product: ,
global:) TracLinks
> > expressions containing whitespaces . For instance the equivalent
of this link
> > `search:"foo bar"` will be `global:"search:foo bar"` or
> > `product:"PREFIX:search:foo bar"` instead of `global:"search:\"foo
bar\""` .
> > More examples in the test cases.
> Search is not resource and I suggest to have search always global. If
user want specify product, syntax may look like:
{{{search:?q=trac+link&product=xxx}}} similar to existing legacy search
syntax e.g.: {{{search:?q=trac+link&wiki=on}}}
Although it is not a true resource, would we naturally expect a search
link specified on a product ticket or wiki page to be searching globally?
It might be an edge case but it does change the scope of such a search if
it is an imported product and we are overriding the existing search
syntax.
Is the search page not going to be available under a product url?
Anyway, I am prepared to accept that this is just an occasional annoyance
that users can fix as long as they can work out how.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:8>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: assigned
Priority: major | Milestone: Release 6
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by jure):
t390_r1455676_product_delimiter_escape.diff applied in r1455836
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:24>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: closed
Priority: major | Milestone: Release 6
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: fixed | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
[attachment:t390_r1455676_product_delimiter_escape.diff Attached patch]
improves HTML escaping .
It also proposes `->` as product delimiter prefix , but it's possible to
skip that part . All tests will pass now for `~` , `>` , `->` and other
*especial* chars .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:21>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by andrej):
Replying to [comment:6 olemis]:
[...]
> - The solution is smart when expanding nested (i.e. product: ,
global:) TracLinks
> expressions containing whitespaces . For instance the equivalent of
this link
> `search:"foo bar"` will be `global:"search:foo bar"` or
> `product:"PREFIX:search:foo bar"` instead of `global:"search:\"foo
bar\""` .
> More examples in the test cases.
Search is not resource and I suggest to have search always global. If user
want specify product, syntax may look like:
{{{search:?q=trac+link&product=xxx}}} similar to existing legacy search
syntax e.g.: {{{search:?q=trac+link&wiki=on}}}
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:7>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: jure
Type: task | Status: closed
Priority: major | Milestone: Release 6
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: fixed | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
Replying to [comment:17 jure]:
>
[...]
>
> note: wikisyntax.diff had `from ImageStat import Stat` as the first line
in `multiproduct/env.py`. removed.
+1 ... that was inserted by PyDev by accident and I did not notice before
submitting the patch .
Thanks
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:20>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
Two pending improvements mentioned in comment:2:ticket:433
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:15>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
Replying to [comment:6 olemis]:
> I'm proposing to new patches for #390 .
Latest submissions are rebased against r1453952
> Observations :
>
> - If you take a look at [http://pastebin.com/PSzv0eZd this test
report]
> including a relevant subset of the test suite affected by these
modifications
> then you might notice that the only failed test cases are
> * those for `TicketQuery` , maybe related to #434
> (@jure @mathevzb could you please take a look ?)
still failing :'(
> * ... and a few more to check for a bizarre case (unicode chars ,
etc ...)
> I'll deal with this one .
The issue with unicode digits is solved after applying
[attachment:t390_r1453952_product_wikisyntax_nomatch.diff this patch] .
[attachment:t390_r1453952_product_ticket_jira.diff Another one] adds
concise JIRA ticket syntax . Finally there is a
[attachment:t390_r1453952_product_wikisyntax_compact.diff third one]
implementing compact product syntax by considering `~` as delimiter
character. In order to use another char just set
`MultiproductSystem.short_syntax_delimiter = THECHAR` and run the test
suite to see if everything is ok .
;)
Patches have to be applied in the following order .
{{{
#!sh
$ hg qapplied
t390/t390_r1453952_product_wikisyntax.diff
t390/t390_r1453952_product_ticket_jira.diff
t390/t390_r1453952_product_wikisyntax_nomatch.diff
t390/t390_r1453952_product_wikisyntax_compact.diff
$ hg log -r qparent --template="[r{svnrev}] {desc}\n"
[r1453952] LRU & LFU cache implementations added, appropriate files
(license, notice,...) updated appropriately
}}}
Decisions have to be made though ; [http://pastebin.com/upWERtuX
2013-03-06 test report] hints us of the fact that the introduction of JIRA
compact ticket syntax will trigger a regression due to the clash with
already supported TracLinks expressions e.g.
{{{
$ python setup.py test -m tests
[...]
======================================================================
FAIL: Test Another arbitrary protocol Link
----------------------------------------------------------------------
Traceback (most recent call last):
File "/path/to/bloodhound/trac/trac/wiki/tests/formatter.py", line 209,
in test
% (msg, self.file, self.line, self.title, formatter.flavor))
AssertionError: u'<p>\n<a class="ext-link"
href="svn+ssh://secureserver.org"><span class="icon"> [truncated]... !=
u'<p>\n<a class="ext-link" href="svn+ssh://secureserver.org"><span
class="icon"> [truncated]...
<p>
<a class="ext-link" href="svn+ssh://secureserver.org"><span
class="icon"></span>svn+ssh://secureserver.org</a>
<a class="ext-link" href="svn+ssh://secureserver.org"><span
class="icon"></span>SVN link</a>
- <a class="ext-link" href="rfc-2396.compatible://link"><span
class="icon"></span>rfc-2396.compatible://link</a>
+ <a class="missing product">rfc-2396</a>.compatible://link
<a class="ext-link" href="rfc-2396.compatible://link"><span
class="icon"></span>RFC 2396</a>
- <a class="ext-link" href="rfc-2396+under_score://link"><span
class="icon"></span>rfc-2396+under_score://link</a>
+ <a class="missing product">rfc-2396</a>+under_score://link
<a class="ext-link" href="rfc-2396+under_score://link"><span
class="icon"></span>underscore</a>
unsafe://scheme is not rendered
</p>
/path/to/bloodhound/trac/trac/wiki/tests/wiki-tests.txt:474: "Another
arbitrary protocol Link" (default flavor)
----------------------------------------------------------------------
}}}
That a test case found in Trac core , not added in the patches mentioned
above . Target wiki test and expected output pasted below
{{{
#!xml
============================== Another arbitrary protocol Link
svn+ssh://secureserver.org
[svn+ssh://secureserver.org SVN link]
rfc-2396.compatible://link
[rfc-2396.compatible://link RFC 2396]
rfc-2396+under_score://link
[rfc-2396+under_score://link underscore]
unsafe://scheme is not rendered
------------------------------
<p>
<a class="ext-link" href="svn+ssh://secureserver.org"><span
class="icon"></span>svn+ssh://secureserver.org</a>
<a class="ext-link" href="svn+ssh://secureserver.org"><span
class="icon"></span>SVN link</a>
<a class="ext-link" href="rfc-2396.compatible://link"><span
class="icon"></span>rfc-2396.compatible://link</a>
<a class="ext-link" href="rfc-2396.compatible://link"><span
class="icon"></span>RFC 2396</a>
<a class="ext-link" href="rfc-2396+under_score://link"><span
class="icon"></span>rfc-2396+under_score://link</a>
<a class="ext-link" href="rfc-2396+under_score://link"><span
class="icon"></span>underscore</a>
unsafe://scheme is not rendered
</p>
------------------------------
}}}
What shall we do ?
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:14>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
Replying to [comment:6 olemis]:
>
[...]
>
> Observations :
>
> - If you take a look at [http://pastebin.com/PSzv0eZd this test
report]
> including a relevant subset of the test suite affected by these
modifications
> then you might notice that the only failed test cases are
> * those for `TicketQuery` , maybe related to #434
> (@jure @mathevzb could you please take a look ?)
> * ... and a few more to check for a bizarre case (unicode chars ,
etc ...)
> I'll deal with this one .
>
[...]
The same statement is true for the whole multi-product test suite (see
[http://pastebin.com/SU87kNUg 4/3/2013 test report] , btw > 1k TCs ...
hooray ! :) . These are the only outstanding issues found in there , thus
deserve our attention and highest priority .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:10>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #390: Product wiki syntax
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#390: Product wiki syntax
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: olemis
Type: task | Status: accepted
Priority: major | Milestone:
Component: | Version:
multiproduct | Keywords: product resource wiki syntax
Resolution: | TracLinks
-------------------------+-------------------------------------------------
Comment (by olemis):
fyi , I refreshed the patch . Please download
[attachment:t390_r1452271_product_wikisyntax.diff.zip zip file] .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/390#comment:13>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker