Enable computed reference to current ticket number

[Patrick Schaaf]

For use in ticket descriptions of parent tickets, as shown on the page for ​ChildTicketsPlugin, it is desirable to automatically refer to the current ticket number when specifying the parent=#xxx macro parameter.

This enables ticket creators to put a ProgressMacro into the description, although at ticket creation time the ticket ID is not yet determined. Some of my users do not have the permission to edit descriptions later, so they cannot fix up the ticket number after the (creation) fact.

[Patrick Schaaf]

add feature to dynamically insert current ticket ID in query parameters

[Patrick Schaaf]

The appended patch makes it possible to put a macro call like this into the ticket description:

[[ProgressMeter(parent=#)]]

I have tested the patch under trac 0.11, only.

My trac is now running with that patch. It would be nice if it could be committed to the ProgressMeter svn in a future revision.

[Patrick Schaaf]

This feature also helps the case where a ticket with embedded progress meter in the description, is cloned, or the description inherited by creating a child ticket. The macro call will continue to work, referring to the newly created ticket.

xref #8962 where the same enhancement is made for TracJSGanttPlugin.

[Andrej Tokarčík]

Hi bof,

I've had a look at your plugin, it looks very good and I'm certainly in favour of such functionality to be included in ProgressMeterMacro. However, there's this thing that concerns me and makes me not accept the patch in its current state...

It is that you assume that every argument accepting ticket ID's would require them to start with a number sign, while an elementary counter-example is even id -- I'd like this argument/field to work since it is part of the default Trac database model. As I see it, the ideal and most clean way of doing this would be if you modified ChildTicketsPlugin so that parent accepts a ticket ID without a number sign (similarly to the id field which could be considered a de facto standard to this end), and I'd apply the patch that replaces kwarg values equal to '#' with (only) the ID number of the actual ticket. What do you think? Would that be possible from your point of view? Then we'd stay aligned with Trac itself and also possibly with other plugins that enhance Trac's ticket system.

Also, I've attached a modified version of your patch with the mentioned changes as well as some other ones, including dealing with possibly confusing behaviour of the processor when previewing a description of a new yet not existing ticket containing a progress meter that points to the ticket being previewed.

Cheers, Andrej

16. S.: I've tested with 0.12, too, and it seems to work. Good work!

[Andrej Tokarčík]

(In [10563]) ProgressMeterMacro: Applied an altered version of bof's patch and thus enabled addressing the actual ticket from within a ProgressMeterMacro call contained in its description; refs #8917.

[Patrick Schaaf]

Sorry, lost sight of this ticket somehow...

In the TracJSGanttPlugin, as well as a nonreleased plugin I am working on, we go with a special parameter value self, instead of a ticket ID! I.e. root=self

It might be a good idea, for consistency, to have parent=self (or even root=self) for ProgressMeter, too, instead of the ugly =#

Regading the check for not-on-newticket: an explicit check for /ticket would be better, because that also catches usage on Wiki pages. Also, instead of raising an error, some kind of dummy display would be preferrable, I think, because otherwise a newticket previewer will think they made a mistake.

Thank you for taking the time to work on this issue!

[Andrej Tokarčík]

(In [10574]) ProgressMeterMacro: Re #8917, 'self' to point to the actual ticket, not '#'.

[Andrej Tokarčík]

Replying to bof:

It might be a good idea, for consistency, to have parent=self (or even root=self) for ProgressMeter, too, instead of the ugly =#

Done.

Regading the check for not-on-newticket: an explicit check for /ticket would be better, because that also catches usage on Wiki pages.

What do you mean? In no place other than /newticket a non-existent 'self' ticket reference should happen.

Also, instead of raising an error, some kind of dummy display would be preferrable, I think, because otherwise a newticket previewer will think they made a mistake.

Yes, that would be nice, but maybe too much of code clutter for such a minor use-case (I for one didn't even know that it's possible to use the macro within a ticket description until I saw your ticket). I'll try to come up with an affordable solution though, at least a plain informational text without the red frame could be better.

[Andrej Tokarčík]

As of [11718], I consider this ticket fully addressed.