Edgewall Software
Modify

Opened 13 years ago

Last modified 5 months ago

#9648 new enhancement

[PATCH] Improve ticket fields with tooltips

Reported by: Sebastian Krysmanski <sebastian@…> Owned by:
Priority: high Milestone: next-major-releases
Component: ticket system Version: 0.12
Severity: normal Keywords: patch fieldrefactoring
Cc: osimons, Thijs Triemstra, Ryan J Ollos Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

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@…> 13 years ago.
patch against Trac 0.12.0
tooltip.png (14.6 KB ) - added by Sebastian Krysmanski <sebastian@…> 13 years ago.
Screenshot

Download all attachments as: .zip

Change History (32)

by Sebastian Krysmanski <sebastian@…>, 13 years ago

Attachment: 200_field-hints.patch added

patch against Trac 0.12.0

by Sebastian Krysmanski <sebastian@…>, 13 years ago

Attachment: tooltip.png added

Screenshot

comment:1 by Remy Blank, 13 years ago

Milestone: 0.13
Owner: set to Remy Blank
Priority: normalhigh

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

in reply to:  1 comment:2 by Christian Boos, 13 years ago

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 by Christian Boos, 13 years ago

Description: modified (diff)

comment:4 by osimons, 13 years ago

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 by Sebastian Krysmanski <sebastian@…>, 13 years ago

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

in reply to:  5 ; comment:6 by Remy Blank, 13 years ago

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.

in reply to:  6 ; comment:7 by osimons, 13 years ago

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.

in reply to:  7 comment:8 by Remy Blank, 13 years ago

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 by Christian Boos, 13 years ago

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

comment:10 by osimons, 13 years ago

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 by shesek, 13 years ago

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.

in reply to:  9 ; comment:12 by Sebastian Krysmanski <sebastian@…>, 13 years ago

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 by Christian Boos, 13 years ago

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

in reply to:  12 ; comment:14 by Remy Blank, 13 years ago

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?

in reply to:  14 ; comment:15 by Sebastian Krysmanski <sebastian@…>, 13 years ago

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.

in reply to:  15 ; comment:16 by Christian Boos, 13 years ago

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

in reply to:  16 comment:17 by Remy Blank, 13 years ago

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 by Christian Boos, 13 years ago

Keywords: fieldrefactoring added

comment:19 by Remy Blank, 13 years ago

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 by Christian Boos, 13 years ago

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

comment:21 by Sebastian Krysmanski <sebastian@…>, 13 years ago

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

in reply to:  21 comment:22 by Remy Blank, 13 years ago

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 by Remy Blank, 13 years ago

Milestone: 0.130.14

comment:24 by Thijs Triemstra, 13 years ago

Cc: Thijs Triemstra added
Summary: Improve ticket fields with tooltips[PATCH] Improve ticket fields with tooltips

comment:25 by jtm.moon.forum.user+trac@…, 10 years ago

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

in reply to:  25 comment:26 by Ryan J Ollos, 10 years ago

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 by Ryan J Ollos, 10 years ago

Cc: Ryan J Ollos added

comment:28 by Ryan J Ollos, 9 years ago

Milestone: next-dev-1.1.xnext-major-releases

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.

comment:29 by Ryan J Ollos, 9 years ago

Owner: Remy Blank removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.