Project-specific ticket prefixes and numbering

[nslowes@…]

With the addition of multiple projects in one Trac instance, it could be helpful to assign ticket identifiers with project-specific prefixes and independent numbering. The prefix would be configured wherever the project is configured. (trac.ini?) This would help differentiate tickets when referring to them by identifier. This is how JIRA assigns ticket identifiers.

For example, in a Trac with two project named Database (DATA) and Web Service (WS), the ticket references would look like:

• DATA-102
• WS-93

With the next Database ticket being assigned DATA-103 and the next Web Service ticket being assigned WS-94. Since changing the way tickets are identified would probably be a huge change, maybe assigned ticket aliases would be a simpler workaround to provide the same functionality? I'm not sure what the best way to use these identifiers as wiki links would be, but the idea is that something like the following could be used to create wiki links:

• WS-93
• ticket:WS-93
• #WS-93
• WS:93 (this might be easiest since you can treat each project prefix as a TracLinks namespace?)

Of course, if the identifier is implemented as an alias then it could get confusing with the underlying numeric identifiers. WS:93 and #342 could point to the same ticket. This also raises the question of what happens if a ticket is moved between projects. I don't have an understanding of the amount of work involved for this type of change, so this is just a suggestion for consideration. I do think it would be very useful for scenarios with 10+ projects sharing a ticket database.

[Christian Boos]

Replying to nslowes@…:

With the addition of multiple projects in one Trac instance, it could be helpful to assign ticket identifiers with project-specific prefixes and independent numbering.

Are you sure independent numbering would be that important? That would make the switch significantly more complex, I believe. But I can also see the advantages, you quickly get a sense of how many tickets were ever created for a given project, and is nice to have when consolidating existing projects.

The prefix would be configured wherever the project is configured. (trac.ini?) This would help differentiate tickets when referring to them by identifier. This is how JIRA assigns ticket identifiers.

For example, in a Trac with two project named Database (DATA) and Web Service (WS), the ticket references would look like:

• DATA-102
• WS-93

With the next Database ticket being assigned DATA-103 and the next Web Service ticket being assigned WS-94. Since changing the way tickets are identified would probably be a huge change, maybe assigned ticket aliases would be a simpler workaround to provide the same functionality?

There would certainly be a solution like that, but more by using id as a surrogate key, which would end up hidden, most of the time (see related discussion for milestones in #9168).

I'm not sure what the best way to use these identifiers as wiki links would be, but the idea is that something like the following could be used to create wiki links:

• WS-93
• ticket:WS-93
• #WS-93

That one would "already" work. The plan is to use the InterTrac prefixes to access to the projects.

• WS:93 (this might be easiest since you can treat each project prefix as a TracLinks namespace?)

With the InterTrac notation, this will have to be WS:ticket:93, unless we also accept the ticket:WS:93 form, which, when written as [ticket:WS:93] would indeed be rendered as WS:93. It remains to be seen if the latter syntax can be extended to all link resolvers.

Of course, if the identifier is implemented as an alias then it could get confusing with the underlying numeric identifiers.

Right, that would be confusing.

WS:93 and #342 could point to the same ticket.

Actually, #342 would point to that ticket in the "current" project or the default project if there's no current project associated with the current Context.

This also raises the question of what happens if a ticket is moved between projects. I don't have an understanding of the amount of work involved for this type of change, so this is just a suggestion for consideration. I do think it would be very useful for scenarios with 10+ projects sharing a ticket database.

With global numbering, that's a non-issue (the main advantage of this option ;-) ), with per-project numbering, this will necessarily imply a change in the ticket number, but the surrogate id would remain the same.

[nslowes@…]

Replying to cboos:

Are you sure independent numbering would be that important? That would make the switch significantly more complex, I believe. But I can also see the advantages, you quickly get a sense of how many tickets were ever created for a given project, and is nice to have when consolidating existing projects.

I don't think its a requirement for managing multiple projects, but I believe it would be a worthwhile enhancement if a simple solution could be found. It makes it easier to refer to tickets in shorthand while also conveying the project context.

I'm not sure what the best way to use these identifiers as wiki links would be, but the idea is that something like the following could be used to create wiki links:

• WS-93
• ticket:WS-93
• #WS-93

That one would "already" work. The plan is to use the InterTrac prefixes to access to the projects.

• WS:93 (this might be easiest since you can treat each project prefix as a TracLinks namespace?)

With the InterTrac notation, this will have to be WS:ticket:93, unless we also accept the ticket:WS:93 form, which, when written as [ticket:WS:93] would indeed be rendered as WS:93. It remains to be seen if the latter syntax can be extended to all link resolvers.

Reviewing the InterTrac syntax, I think that would get really close to the desired behavior. #WS-93 is a good way to quickly create links. [WS:ticket:93] is also acceptable, even if [ticket:WS:93] would be a little better.

Would the InterTrac link resolver be able to deal with the extra "-" notation for #WS-93, or would "WS-" need to be added as an explicit prefix? #WS93 is a little bit harder to read. Also, would the projet prefix be configurable through the Admin GUI?

Actually, #342 would point to that ticket in the "current" project or the default project if there's no current project associated with the current Context.

I'm not sure I understand this. For example, does this mean that all wiki resources will be linked to a project, such that #342 will always refer to ticket 342 in the associated project, and a link to ticket 342 in a different project would have to be written using an InterTrac prefix? This would work for resolving the links, but I think it would get confusing for rendering the links when a different center of interest is selected.

If you are viewing a "Project A" wiki page in the context of the toplevel project "/", and you see #342 on the page, you may expect that to be link to the toplevel ticket 342, when it in fact links to Project A ticket 342. The same problem exists with the scenario reversed (viewing a toplevel wiki page with Project A as center of interest). Am I inappropriately associating Context with center of interest? (As described in TracDev/Proposals/MultipleProject)

[Christian Boos]

Replying to nslowes@…:

Reviewing the InterTrac syntax, I think that would get really close to the desired behavior. #WS-93 is a good way to quickly create links. [WS:ticket:93] is also acceptable, even if [ticket:WS:93] would be a little better.

Would the InterTrac link resolver be able to deal with the extra "-" notation for #WS-93,

That should be doable, yes.

Also, would the projet prefix be configurable through the Admin GUI?

It could be a normal [intertrac] alias (i.e. WS = webservice, with webservice being the project identifier).

Actually, #342 would point to that ticket in the "current" project or the default project if there's no current project associated with the current Context.

does this mean that all wiki resources will be linked to a project, such that #342 will always refer to ticket 342 in the associated project, and a link to ticket 342 in a different project would have to be written using an InterTrac prefix?

Right. The alternative would be to always require the prefix, which would be impractical for importing existing projects, and even not possible without major hassle for existing ticket references in commit messages (and btw. this latter requirement pretty much mandates some sort of solution for the present ticket ;-) ).

This would work for resolving the links, but I think it would get confusing for rendering the links when a different center of interest is selected.

Well, rendering is "our" business ;-) If rendering a #342 link as #342 proves to be too confusing in a multiple project setup, we can decide to always render it as #WS-342.

Am I inappropriately associating Context with center of interest? (As described in TracDev/Proposals/MultipleProject)

Yes, sorry I was not clear. Context in the above meant trac.mimeview.Context, i.e. the WikiContext, which tells the rendering system to which resource the content is associated with, who is viewing it, in which format, etc. This is what enables e.g. the timeline to redirect you to the proper ticket when clicking on a comment:1 link.

[nslowes@…]

Replying to cboos:

does this mean that all wiki resources will be linked to a project, such that #342 will always refer to ticket 342 in the associated project, and a link to ticket 342 in a different project would have to be written using an InterTrac prefix?

Right. The alternative would be to always require the prefix, which would be impractical for importing existing projects, and even not possible without major hassle for existing ticket references in commit messages (and btw. this latter requirement pretty much mandates some sort of solution for the present ticket ;-) ).

I don't think I understand how this will work for commit references. I can see a potential problem resolving those references, since they cannot be changed, so the changesets will have to be associated with a project so that the Context can determine the correct ticket. Thinking about my current Trac setup, we have one repository that hosts many projects. If/when we eventually migrate to a multiproject setup in Trac 0.13, we would want to move tickets and wiki resources into separate projects, but our code would still be stored in the same repository.

I tried to look in TracRepositoryAdmin to see if the multiple repository support allows you to use sub-paths of a repository as the Trac repository root, but I didn't find an answer. The idea would be that "http://example.com/svn/myrepos/project1" and "http://example.com/svn/myrepos/project2" would be different repositories in Trac even though they are the same repository in SVN. However this would still not solve the ticket reference problem, because even if this is possible, the ticket references would now point to the correct project but likely the wrong ticket number. Is this the problem you were alluding to in your reply?

[Christian Boos]

Replying to nslowes@…:

I don't think I understand how this will work for commit references. … we have one repository that hosts many projects. If/when we eventually migrate to a multiproject setup in Trac 0.13, we would want to move tickets and wiki resources into separate projects, but our code would still be stored in the same repository.

The base idea was #978, but this is not enough in your scenario.

For example, let's say you have:

• r1501/project1 saying "Fixed #203"
• r1502/project2 saying "Fixed #302"
• move to subproject happens after r8483
• r8501 (in project1 repos) saying "Fixed #1003"
• r8502 (in project2 repos) saying "Fixed #1002"

If #203 is later moved to WS (and therefore renamed to e.g. #WS-93) and #302 to DATA (#DATA-102), then we have to keep the old references #203 and #302 working, and have new references resolved directly to #WS-1003 and #DATA-1002.

This could work with an extension of the base idea of #978 if we would indicate ranges: e.g. project1 repos could be associated to the default project (or some "legacy" project containing the original ticket #203) for the 1-8483 range, and to WS after that revision, and similarly project2 to DATA. The #203 (or #legacy-203 ticket) would also have to be aliased to #WS-93 after the move, like discussed in #3718 for milestones.

I tried to look in TracRepositoryAdmin to see if the multiple repository support allows you to use sub-paths of a repository as the Trac repository root

Yes, that was always possible (for Subversion repositories at least), see TracEnvironment#SourceCodeRepository.

[StasAgarkov <stas.agarkov@…>]

this functionality will be implemented?

[dreel@…]

Why don't we use global ticket counter like Redmine does?