autocomplete other fields (reporter and keywords)

[Vincent]

Why not extend Autocomplete to the ticket fields 'reporter' and 'keywords'? Could save time :-)

[Ryan J Ollos]

Changing ticket owner to be new maintainer.

[Ryan J Ollos]

Keyword autocompletion is handled by the KeywordSuggestPlugin. This plugin could be extended to handle the reporter field though.

[Ryan J Ollos]

(In [11736]) Refs #6444: Added support for autocompleting the Reporter field on the ticket page.

[falkb]

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?

[Ryan J Ollos]

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.

[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 and autocomplete-users&groups.

Or is there a better way to extend this functionality to other plugins?

[falkb]

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.

[Ryan J Ollos]

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.

[Ryan J Ollos]

#10417 closed as a duplicate.

[Cauly]

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 and autocomplete-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.

[Ryan J Ollos]

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 call autocomplete on the selector, like in autocompleteusersplugin/trunk/autocompleteusers/htdocs/js/autocomplete_ticket.js.

[Ryan J Ollos]

In 17200:

TracAutocompleteUsersPlugin 0.4.5dev: Combine ticket and newticket scripts

Refs #6444.

[Ryan J Ollos]

The following patch may be sufficient:

autocompleteusers/htdocs/js/autocomplete_ticket.js

@@ -1 +1 @@
 jQuery(function ($) {
   var path = newticket ? "subjects" : "../subjects"
 
-  $("#field-owner, input:text#field-reporter, #action input:text[id$=_reassign_owner]").autocomplete(path, {
+  $("#field-owner, input:text#field-reporter, #action input:text[id$=_reassign_owner], .trac-autocomplete").autocomplete(path, {
     formatItem: formatItem
   });
 
-  $("#field-cc").autocomplete(path, {
+  $("#field-cc, .trac-autocomplete-multi").autocomplete(path, {
     multiple: true,
     formatItem: formatItem,
     delay: 100

If you were to test the patch and modify FieldOfTablePlugin, then I would commit the change.

[Ryan J Ollos]

I unintentionally captured the comment:16 change in r17203. So it's already there to test.