ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Long format issue/revision links (Feature #207)

Added by Ian Freeman at 2011-02-19 12:27 am. Updated at 2011-02-19 11:07 pm.

Status:Open Start date:2011-02-19
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:Text formatting
Target version:-
Remote issue URL: Affected version:

Description

Allow an alternate more descriptive linking syntax for common link types like issues and revisions anywhere wiki format is accepted (especially issue comments).

The base code already has such a feature, for instance the link that is displayed for a related issue is more descriptive than just #207.

One approach for issues:
#207 becomes #207
##207 becomes Feature 207
###207 becomes Feature 207: Long format issue/revision links

You could also do s and l suffixes for short and long links, although l could be easily confused with 1 when editing.

An alternate approach, using extra characters to manually layout the text:
#207n or simply #207 becomes #207
#207tn becomes Feature 207
#207tns becomes Feature 207: Long format issue/revision links
n stands for number.
t stands for tracker.
s stands for subject.

You could even allow regex, but that's going overboard:
#207/n \(t\): s by a/ becomes 207 (Feature): Long format issue/revision links by Ian Freeman
n, t, s, a would all need to be special codes (can be escaped with \).

I would like to use this feature to help me build changelog wikis that I generate and link to every new version entry in my active projects.

History

#1
Updated by Eric Davis at 2011-02-19 01:48 am

What about a wiki macro? I have a plugin with one that outputs a bunch of information. See the readme and example image: redmine_wiki_issue_details

We could have something like:

  • {issue(100)} - "#100"
  • {issue(100, 'tracker id')} - "Feature #100"
  • {issue(100, 'tracker id subject')} - "Feature #100 The subject"
  • {issue(100, 'Some extra text with id before subject')} - "Some extra text with #100 before The subject"

(the string is just searched and replaced based on a list of valid field names)

  • Category changed from Wikis to Text formatting

#2
Updated by Aleksey Zapparov at 2011-02-19 11:54 am

That's a great idea, but I propose to have a little bit different syntax:

  • {issue(100)} - "#100"
  • {issue(100, :tracker, :id)} - "Feature #100"
  • {issue(100, :tracker, :id, :subject)} - "Feature #100 The subject"
  • {issue(100, 'Some extra text with ', :id, ' before subject')} - "Some extra text with #100 before The subject"

#3
Updated by Holger Just at 2011-02-19 01:16 pm

I fear, the macro syntax is not that rich (though, I'm inclined to change that :), probably for 2.0.0 release).

Here, I propose a simple templating language to distinguish the text from fields. It could be one of the following:

  • ! -> "Feature #100 The subject"
  • ! - "Some extra text with #100 before The subject"
  • # ")}} -> "Feature #100 The subject"
  • before ")}} - "Some extra text with #100 before The subject"

I think the second variant is not expressible currently, as the regex to parse the macros does not take quotation, escaping or nesting into account.

But more generally, the macro method should only be used in addition to the original proposal of using more hashes for longer formats (which I really like). That way, the format could be changed globally and it is really simple to use. Normal users are not too convinced by that macro syntax I'm afraid...

#4
Updated by Aleksey Zapparov at 2011-02-19 01:51 pm

Another few cents :)) Probably to make it a little bit more natural:

  • #207 -> #207
  • #207:"Some alt. description of is just a template"

This will also allow to define default template, let's say " ", so #207 will become Feature #207

#5
Updated by Ian Freeman at 2011-02-19 04:06 pm

I'm happy with any of the macro solutions.

Holger Just wrote:

But more generally, the macro method should only be used in addition to the original proposal of using more hashes for longer formats (which I really like).

I really like this idea. Whichever more complicated macro syntax we should use, multiple OCTOTHORPEs should be used for users that don't care to use it.

But I don't like the double hash syntax you propose in the first example, I can see users getting confused with the sub-list ## directive.

#6
Updated by Eric Davis at 2011-02-19 11:07 pm

Holger Just wrote:

I fear, the macro syntax is not that rich (though, I'm inclined to change that :), probably for 2.0.0 release).

1output = args[1].gsub('id', issue.id).gsub('subject', issue.subject)
2return h(output)

Here, I propose a simple templating language to distinguish the text from fields.

If we are going to use a template language then we shouldn't invent our own, there are too many edge cases and it's easy to miss one and have a security hole. Liquid templates are a safer solution and might be useful in other places too (theming). But I think that is overkill for this.

But more generally, the macro method should only be used in addition to the original proposal of using more hashes for longer formats (which I really like).

Personally I don't like the extended hash syntax. Issue number are already different than any other object linking (object:"text" syntax description)

Also available in: Atom PDF