[PATCH] Improve ticket fields with tooltips

[Sebastian Krysmanski <sebastian@…>]

I've created a patch that allows a Trac admin to specify tooltips for arbitrary ticket fields in Trac:

This way the admin can explain a certain field in more detail (for example the difference between priority and severity) or provide information about the syntax used in that field.

The tooltips appear in the following places:

• the ticket box on the top of an existing ticket page (only on labels, not on values)
• in the ticket history for changes values
• the ticket input fields (on labels and input fields)

All labels get a help cursor if a tooltip is available.

Tooltips are specified in the trac.ini under the new section [ticket-hints]. Just assign the tooltip value to the name of the field. The user may also provide the same tooltip in multiple languages by appending the language code to the field name. Works for built-in fields as well as for custom fields (this patch is a generalization of #899). Example:

[ticket-hints]
reporter = The reporter of this ticket
owner = The owner of this ticket

blockedby = Tickets preventing this one from closing. Accepts comma delimited ticket number (without #)

complexity = The estimated complexity involved in fixing this ticked.
complexity_de = Die geschätzte Komplexität zur Lösung des Tickets

I've decided to use the trac.ini for localization as it would be too much overhead to create translation files for just some tooltips.

[Sebastian Krysmanski <sebastian@…>]

patch against Trac 0.12.0

[Sebastian Krysmanski <sebastian@…>]

Screenshot

[Remy Blank]

Looks nice! I wonder if it wouldn't be better to handle the hints in the same way as the ticket field labels, i.e. inside TicketSystem.get_ticket_fields(), instead of adding a new method get_field_hints().

[Christian Boos]

Replying to rblank:

Looks nice! I wonder if it wouldn't be better to handle the hints in the same way as the ticket field labels, i.e. inside TicketSystem.get_ticket_fields(), instead of adding a new method get_field_hints().

Yes, and re-use [ticket-custom] for having a .hint counterpart to .label. The localizations could be done via .hint.de and we'd get support for .label.de at little cost, then. I also see no problem in taking extra informations for standard fields from the [ticket-custom] section, which would then stand for "ticket customizations" rather than "ticket custom fields". We would have in one place the labels, hints and their translations, for standard and custom fields.

[osimons]

Just adding myself to cc to keep an eye on progress here.

I would need to integrate this into my ​th:CustomFieldAdminPlugin if it becomes part of Trac - or perhaps this is a good time to add the plugin features to Trac and provide integrated field management?

[Sebastian Krysmanski <sebastian@…>]

An alternative would be to create a trac.ini editor. Not as convenient as a customized editor but still a viable option.

[Remy Blank]

Replying to Sebastian Krysmanski <sebastian@…>:

An alternative would be to create a trac.ini editor.

I have been wanting something like that for a long time, too. As long as it can easily be disabled, I'd be +1.

[osimons]

Replying to rblank:

Replying to Sebastian Krysmanski <sebastian@…>:

An alternative would be to create a trac.ini editor.

I have been wanting something like that for a long time, too. As long as it can easily be disabled, I'd be +1.

No thanks. Install the ​th:IniAdminPlugin if you want plain trac.ini writing via web admin. A ticket field editor should be something more than this.

[Remy Blank]

Replying to osimons:

No thanks. Install the ​th:IniAdminPlugin if you want plain trac.ini writing via web admin. A ticket field editor should be something more than this.

The intention was not for this to be the solution for editing custom ticket fields, just a means of editing trac.ini without going to a shell.

I prefer hand-editing trac.ini, and I would see at least some value in being able to do it in an admin panel. I don't want a fancy per-field display, and until #7378 is fixed, neither CustomFieldAdmin nor IniAdminPlugin are usable for me, as I keep comments in trac.ini.

Wrong thread, I guess…

[Christian Boos]

Ok, back on tracks for the immediate action, what's your take on comment:1 and comment:2 Sebastian?

[osimons]

BTW, forgot to say that I'm all for keeping things inside the [ticket-custom] section. Anything in that section that isn't based on a custom field definition (myfield = text) and corresponding prefix (myfield.*) are just ignored by the custom field mechanism (and my admin plugin). It makes sense to handle extensions for regular fields the same way as custom fields hints and labels.

[shesek]

You can also use ​qTip for some added shininess. It based on jQuery, degrades well and can be easily set-up to use the title attributes you're already setting. Its also quite easy to make it appear next to the input when its focused.

[Sebastian Krysmanski <sebastian@…>]

Replying to cboos:

Ok, back on tracks for the immediate action, what's your take on comment:1 and comment:2 Sebastian?

I thought about using [ticket-custom] but created a new section since I thought that this section was only for custom ticket fields. However, if it's ok to reinterpret this section to "ticket customization" than there's no problem of doing it like cboos said.

Regarding using get_ticket_fields(): I'm not sure how you would suggest that this feature could be implemented using get_ticket_fields() (other than completely rewriting a lot of code). Sure, it could be done by adding a hint "field" to the ticket field dict, but there are a few points that need to be kept in mind:

• We need a dict whose keys are the field names. Currently (without my patch) only a list of ticket fields is passed as data which makes it complicate to find a certain field. This is necessary for example for the "reporter" or "owner" since they're no handled from within the field loops in the template files.
• I tried to create a patch that can be easily maintained (since I didn't know what the reponse to the feature would be). So I tried to rewrite as little code as possible. Implementing the whole feature using get_ticket_fields() would require (a lot) more code changes than my patch - at least I think.

I can try to implement both suggestions and then attach the new patch here (unless someone else wants to do this).

Just another two notes:

• "qTip" looks nice though I doubt that the extra payload will bring any substantial use.
• Offtopic: I've started to create a trac.ini editor (sources ​here). I will create a ticket for this in the next few day so stay tuned.

[Christian Boos]

#7640 also suggests to make the order of all fields (standard and custom) configurable, something we could achieve with [ticket-custom] as well, and even better than with the .order fields if we'd have our custom .ini reader… (#7378).

About qTip: looks nice but overkill to me, let's see what we could do with jQuery UI / position (or even plain jQuery).

[Remy Blank]

Replying to Sebastian Krysmanski <sebastian@…>:

Regarding using get_ticket_fields(): I'm not sure how you would suggest that this feature could be implemented using get_ticket_fields() (other than completely rewriting a lot of code).

This could be done the same way as the field labels, by translating in get_ticket_fields(). What is not so clear is how to handle the translation. Maybe we could load all translations as a catalog while caching the fields in field(), and use Babel's standard machinery in get_ticket_fields()?

• We need a dict whose keys are the field names.

Why? If the hint is part of the field "attributes" in each field dict, it is readily available while iterating over the fields.

This is necessary for example for the "reporter" or "owner" since they're no handled from within the field loops in the template files.

Well, a list comprehension also works nicely here.

Implementing the whole feature using get_ticket_fields() would require (a lot) more code changes than my patch - at least I think.

I'm not sure about "a lot", but conceptually the hint is an attribute of the field, and so get_ticket_fields() is the logical location to add it.

I can try to implement both suggestions and then attach the new patch here

Yes, please do.

• Offtopic: I've started to create a trac.ini editor (sources ​here).

What's the difference with ​th:IniAdminPlugin?

[Sebastian Krysmanski <sebastian@…>]

Replying to rblank:

This could be done the same way as the field labels, by translating in get_ticket_fields(). What is not so clear is how to handle the translation. Maybe we could load all translations as a catalog while caching the fields in field(), and use Babel's standard machinery in get_ticket_fields()?

I'm against using Babel catalogue files here as they're not as easily maintainable by the admin as editing the trac.ini file. So I wouldn't implement this feature any other way it's implemented now (except there are some pressing needs).

• We need a dict whose keys are the field names.

Why? If the hint is part of the field "attributes" in each field dict, it is readily available while iterating over the fields.

Yes, but finding a specific field inside a list is much slower than finding a field in a dict. And this is at least needed for "reporter", "owner", and "description". So again, we need a dict here (unless you guys don't care about speed) and I don't see a reason why to stick to a list.

• Offtopic: I've started to create a trac.ini editor (sources ​here).

What's the difference with ​th:IniAdminPlugin?

Not much (which I just found out). The editor represents the trac.ini file as "pair:value" list (instead of group boxes), it allows you to add new fields (which would be needed for this ticket) and new sections, and has some optional JavaScript stuff that makes editing easier.

[Christian Boos]

Replying to Sebastian Krysmanski <sebastian@…>:

Replying to rblank:

This could be done the same way as the field labels, by translating in get_ticket_fields(). What is not so clear is how to handle the translation. Maybe we could load all translations as a catalog while caching the fields in field(), and use Babel's standard machinery in get_ticket_fields()?

I'm against using Babel catalogue files here as they're not as easily maintainable by the admin as editing the trac.ini file.

I think you misunderstood Remy's point. The source of translations themselves would still be in the .ini (your way <field>.label_de or <field>.label.de), but if we want to use the convenient gettext(), we could populate a catalog programmatically, and use that. However, I'm not sure this is feasible, and if this implies using a separate catalog and domain, we would need to perform two gettext calls anyway (a dgettext first and a gettext fallback). If that's the case, we could as well perform a direct lookup in the config first.

• We need a dict whose keys are the field names.

Why? If the hint is part of the field "attributes" in each field dict, it is readily available while iterating over the fields.

Remy, didn't you implement something like that anyway in [bdb2c482fb43/rblank]? Well, close ;-) We could just use the reverse approach, and have a Fields class which inherits or behaves like a dict. TicketSystem.get_ticket_fields would still take care about the sequence and return a list (for backward compatibility), but a new API could be to define keys() and an iterator on Fields which would take the order out of the .ini file (defaults to a "base" order set in the constructor or Fields subclass).

Yes, but finding a specific field inside a list is much slower than finding a field in a dict.

We do care. But the above refactoring would mainly pay off by reducing the need to do a deepcopy() everytime we access the fields. We could have TicketSystem(env).fields.label('reporter') to do the appropriate gettext lookup without the need to modify the fields data itself.

Time for some coding experimentation I suppose ;-)

[Remy Blank]

Replying to cboos:

The source of translations themselves would still be in the .ini (your way <field>.label_de or <field>.label.de), but if we want to use the convenient gettext(), we could populate a catalog programmatically, and use that.

Yes, that's what I meant. It was just an idea, not sure either if it's feasible / sensible.

Remy, didn't you implement something like that anyway in [bdb2c482fb43/rblank]? Well, close ;-) We could just use the reverse approach, and have a Fields class which inherits or behaves like a dict. TicketSystem.get_ticket_fields would still take care about the sequence and return a list (for backward compatibility), but a new API could be to define keys() and an iterator on Fields which would take the order out of the .ini file (defaults to a "base" order set in the constructor or Fields subclass).

Yes, I experimented with that in #1942, but I wanted to limit the changes, hence the list-with-additional-method approach. The bigger changes should really go in FieldRefactoring (that is, I'd rather not add too many new interfaces to the ticket fields).

We could have TicketSystem(env).fields.label('reporter') to do the appropriate gettext lookup without the need to modify the fields data itself.

This would already be possible by extending my changes from #1942, wouldn't it?

[Remy Blank]

I'm trying to implement custom field label translation as suggested above. How can I get the name of the currently active locale (i.e. "fr" or "en_US")?

[Christian Boos]

Looks like it's not possible, we should probably add it ourselves as property to our Translations instances (in TranslationsProxy.activate).

[Sebastian Krysmanski <sebastian@…>]

What's with the solution I used in my patch?

[Remy Blank]

Replying to Sebastian Krysmanski <sebastian@…>:

What's with the solution I used in my patch?

I'm coming to that, but first I wanted to see if my suggestion from comment:1 made sense or not. So I dug out the "keyed" list from #1942 and tried to extend it to handle field label translations first (do we have a ticket for that, btw?).

[jtm.moon.forum.user+trac@…]

I'm unable to get tooltips working using trac 0.12.2 .
Are there finalized instructions for enabling this?

[Ryan J Ollos]

Replying to jtm.moon.forum.user+trac@…:

I'm unable to get tooltips working using trac 0.12.2 .
Are there finalized instructions for enabling this?

You might be better off trying to use ​th:FieldTooltipPlugin.

[Ryan J Ollos]

Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.

[Ryan J Ollos]

Requested in ​gmessage:trac-users:VWqhfrHU5Ak/K3B0teZNCQAJ.