On 2/20/13, Gary Martin <[email protected]> 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.
