Edgewall Software
Modify

Opened 4 years ago

Last modified 3 months ago

#9648 new enhancement

[PATCH] Improve ticket fields with tooltips

Reported by: Sebastian Krysmanski <sebastian@…> Owned by: rblank
Priority: high Milestone: next-dev-1.1.x
Component: ticket system Version: 0.12
Severity: normal Keywords: patch fieldrefactoring
Cc: osimons, thijstriemstra, rjollos
Release Notes:
API Changes:

Description (last modified by cboos)

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

Screenshot

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.

Attachments (2)

200_field-hints.patch (9.7 KB) - added by Sebastian Krysmanski <sebastian@…> 4 years ago.
patch against Trac 0.12.0
tooltip.png (14.6 KB) - added by Sebastian Krysmanski <sebastian@…> 4 years ago.
Screenshot

Download all attachments as: .zip

Change History (29)

Changed 4 years ago by Sebastian Krysmanski <sebastian@…>

patch against Trac 0.12.0

Changed 4 years ago by Sebastian Krysmanski <sebastian@…>

Screenshot

comment:1 follow-up: Changed 4 years ago by rblank

  • Milestone set to 0.13
  • Owner set to rblank
  • Priority changed from normal to high

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().

comment:2 in reply to: ↑ 1 Changed 4 years ago by cboos

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.

comment:3 Changed 4 years ago by cboos

  • Description modified (diff)

comment:4 Changed 4 years ago by osimons

  • Cc osimons added

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?

comment:5 follow-up: Changed 4 years ago by 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.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 4 years ago by 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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 4 years ago by 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.

comment:8 in reply to: ↑ 7 Changed 4 years ago by rblank

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…

comment:9 follow-up: Changed 4 years ago by cboos

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

comment:10 Changed 4 years ago by 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.

comment:11 Changed 4 years ago by 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.

comment:12 in reply to: ↑ 9 ; follow-up: Changed 4 years ago by 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.

comment:13 Changed 4 years ago by cboos

#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).

comment:14 in reply to: ↑ 12 ; follow-up: Changed 4 years ago by rblank

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?

comment:15 in reply to: ↑ 14 ; follow-up: Changed 4 years ago by 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.

comment:16 in reply to: ↑ 15 ; follow-up: Changed 4 years ago by cboos

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 ;-)

comment:17 in reply to: ↑ 16 Changed 4 years ago by rblank

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?

comment:18 Changed 4 years ago by cboos

  • Keywords fieldrefactoring added

comment:19 Changed 4 years ago by rblank

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")?

comment:20 Changed 4 years ago by cboos

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

comment:21 follow-up: Changed 4 years ago by Sebastian Krysmanski <sebastian@…>

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

comment:22 in reply to: ↑ 21 Changed 4 years ago by rblank

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?).

comment:23 Changed 4 years ago by rblank

  • Milestone changed from 0.13 to 0.14

comment:24 Changed 4 years ago by thijstriemstra

  • Cc thijstriemstra added
  • Summary changed from Improve ticket fields with tooltips to [PATCH] Improve ticket fields with tooltips

comment:25 follow-up: Changed 13 months ago by jtm.moon.forum.user+trac@…

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

comment:26 in reply to: ↑ 25 Changed 13 months ago by rjollos

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.

comment:27 Changed 3 months ago by rjollos

  • Cc rjollos added

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new The owner will remain rblank.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from rblank to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.