#6444 closed enhancement (wontfix)
autocomplete other fields (reporter and keywords)
Reported by: | Vincent | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | normal | Component: | AutocompleteUsersPlugin |
Severity: | normal | Keywords: | |
Cc: | Jun Omae, falkb | Trac Release: | 0.11 |
Description
Why not extend Autocomplete to the ticket fields 'reporter' and 'keywords'? Could save time :-)
Attachments (0)
Change History (17)
comment:1 Changed 14 years ago by
Owner: | changed from Jeff Hammel to Ryan J Ollos |
---|
comment:2 Changed 12 years ago by
Keyword autocompletion is handled by the KeywordSuggestPlugin. This plugin could be extended to handle the reporter field though.
comment:3 Changed 12 years ago by
Cc: | Jun Omae falkb added; anonymous removed |
---|---|
Status: | new → assigned |
comment:4 Changed 12 years ago by
comment:5 Changed 12 years ago by
I wonder if autocompletion of fields can be generic in general also for all freely editable fields. For example I have custom ticket field "projects" and users asked me here how they can predict the available names on page "View Tickets"-->"Custom Query". Well, I think about copying your appropriate code to SimpleMultiProjectPlugin but would be cool if it was generic in general. What do you think about this topic?
comment:6 Changed 12 years ago by
At first I read your question as, how can we extend the plugin to autocomplete a user text field on any Trac page?, and I realize now that isn't your specific question, but let me comment on that briefly since I had thought about it before. It would probably be possible to specify a list of paths and selectors in trac.ini and use that information to either modify the Genshi template in ITemplateStreamFilter
to add an autocomplete
class to the specified elements, or use add_script_data
in Trac 0.12 to do all the work in JavaScript.
As for autocompleting fields other than the users field, I tend to think that the jQuery is simple enough that you may just want to implement this directly in your codebase. However, KeywordSuggestPlugin is very similar to this plugin, with the main exception being how the data is stored, and looking for commonality between KeywordSuggestPlugin and AutocompleteUsersPlugin could be a good starting point.
I'd like to figure out how to pull the data directly from the Trac database without having an intermediate /subjects
page. We might be able to have some reusable code that takes a database table/column and a selector as arguments, and does all the work of autocompleting any text field. We could then put this project in Trac-Hacks and plugins that need the code could use an svn:externals
to pull it in.
comment:7 follow-up: 12 Changed 12 years ago by
Rather than binding the autocompleter to specific element ids, what do you guys think about adding a class to all elements that we'd like to autocomplete, and then binding the autocompleter to the class? That would allow falkb to autocomplete fields for his SimpleMultiProjectPlugin, and I also have a use-case for this now with the DefaultCcPlugin. I'm not sure though how we'd cleanly differentiate between autocompleting users, groups and both users and groups, but it could be a matter of having several classes: autocomplete-users
, autocomplete-groups
and autocomplete-users&groups
.
Or is there a better way to extend this functionality to other plugins?
comment:8 Changed 12 years ago by
Uhm...for my needs, it would mean to autocomplete a custom ticket field "project" and offer the projects I actually retrieve somehow from the db with simplemultiprojectplugin/trunk/simplemultiproject/model.py#L71. A general solution for autocompletion would likely need a callback function pointer returning a stringlist it uses to work on.
comment:9 Changed 12 years ago by
In that case, I tend to think you are better-off just using Autocomplete from the jQuery UI. Your use case sounds almost exactly like KeywordSuggestPlugin.
It would be nice to generalize AutocompleteUsersPlugin to autocomplete user fields everywhere they are found though, including in plugins, provided the plugin author has take care to do whatever is required to extend the autocomplete functionality to that field.
comment:10 Changed 12 years ago by
Status: | assigned → new |
---|
comment:12 follow-up: 14 Changed 7 years ago by
Replying to Ryan J Ollos:
Rather than binding the autocompleter to specific element ids, what do you guys think about adding a class to all elements that we'd like to autocomplete, and then binding the autocompleter to the class? That would allow falkb to autocomplete fields for his SimpleMultiProjectPlugin, and I also have a use-case for this now with the DefaultCcPlugin. I'm not sure though how we'd cleanly differentiate between autocompleting users, groups and both users and groups, but it could be a matter of having several classes:
autocomplete-users
,autocomplete-groups
andautocomplete-users&groups
.Or is there a better way to extend this functionality to other plugins?
After a quick glance at code it seems that the idea of binding autocomplter to class is not yet implemented. I think it's quite a good idea, since there's need to use this at FieldOfTablePlugin. See comment:5:ticket:12523.
comment:13 Changed 7 years ago by
Status: | new → accepted |
---|
comment:14 Changed 7 years ago by
Resolution: | → wontfix |
---|---|
Status: | accepted → closed |
Replying to Cauly:
After a quick glance at code it seems that the idea of binding autocomplter to class is not yet implemented. I think it's quite a good idea, since there's need to use this at FieldOfTablePlugin. See comment:5:ticket:12523.
PatchWelcome, however you already have two options:
- Specify the field in
[autocomplete]
fields
: AutocompleteUsersPlugin#Configuration - Test for autocomplete in your JavaScript (
if ($.isFunction($.fn.autocomplete))
) and then callautocomplete
on the selector, like in autocompleteusersplugin/trunk/autocompleteusers/htdocs/js/autocomplete_ticket.js.
comment:16 Changed 7 years ago by
The following patch may be sufficient:
-
autocompleteusers/htdocs/js/autocomplete_ticket.js
1 1 jQuery(function ($) { 2 2 var path = newticket ? "subjects" : "../subjects" 3 3 4 $("#field-owner, input:text#field-reporter, #action input:text[id$=_reassign_owner] ").autocomplete(path, {4 $("#field-owner, input:text#field-reporter, #action input:text[id$=_reassign_owner], .trac-autocomplete").autocomplete(path, { 5 5 formatItem: formatItem 6 6 }); 7 7 8 $("#field-cc ").autocomplete(path, {8 $("#field-cc, .trac-autocomplete-multi").autocomplete(path, { 9 9 multiple: true, 10 10 formatItem: formatItem, 11 11 delay: 100
If you were to test the patch and modify FieldOfTablePlugin, then I would commit the change.
comment:17 Changed 7 years ago by
I unintentionally captured the comment:16 change in r17203. So it's already there to test.
Changing ticket owner to be new maintainer.