Re: extending tickets autocomplete

Am 23.06.2014 19:20, schrieb Alex Vandiver:
> On 06/20/2014 03:18 AM, Christian Loos wrote:
>> for a custom ticket create form I need an ticket autocomplete which
>> limit the returned tickets by queues and customfield values.
>>
>> Creating a new helper isn't sufficient because the autocomplete helper
>> names are hard coded in share/static/js/autocomplete.js.
>>
>> Thinking about making the ticket autocomplete more flexible I came up
>> with two solutions:
>>
>> 1. change share/static/js/autocomplete.js to match for the end of the
>> helper name, so a new FooBarTickets helper is treated the same as the
>> Tickets helper
> 
> Hm.  I think I'm vaguely in favor of this, since it allows easy
> extensibility for, say, Assets.  But, as you note, several places
Good idea: autocomplete Assets. Also autocomplete Articles comes in my mind.

> hardcode behavior changes based on what = "Tickets" -- are you
> suggesting that it would match data-autocomplete="FooBarTickets" and
> parse out the Tickets, and perform the remained of the function with
> what = "Tickets", but call /Helpers/Autocomplete/FooBarTickets ?
Currently the main difference between the autocomplete helpers are the
delimiter and [1]. Maybe for 4.4 we can use the same delimiter on all
autocompletes. Is there a reason for the different delimiters?
If we have to stay with different delimiters we can use a new
data-autocomplete-delimiter to tell autocomplete.js which delimiter to
pass to the helper.
I'm currently not sure how to handle [1] if we don't want to hardcode
"what" in autocomplete.js. The idea was exactly what you described
above, which would help to write custom ticket autocomplete helpers.

> 
>> 2. add the possibility to use a new data-autocomplete-query attribute
>> which lets you define some ticket sql which is added to the query in
>> share/html/Helpers/Autocomplete/Tickets
> 
> This goes down the path of specializing ticket autocomplete more, rather
> than giving us more rope for other kinds of autocomplete, so I think I'd
> prefer an alternate solution.
> 
>> Also, what is the use case for the cssClassMap in
>> share/static/js/autocomplete.js?
>> I couldn't find anything that uses this css classes in the code.
> 
> Explained in 315f007faed524e600c2c13fc4c13d8ebfa1e456 -- but I believe
> that the reason is now moot, since the data-autocomplete="User" selector
> pretty much fulfills that need.
I would simply replace here [2] "cssClassMap[what]" by
"what.toLowerCase()" to remove hardcoding what and still adding the same
class if someone use this.

Next I have time (probably after my vacation) I will create a
PullRequest for this.


Chris

[1]
https://github.com/bestpractical/rt/blob/stable/share/static/js/autocomplete.js#L50
[2]
https://github.com/bestpractical/rt/blob/stable/share/static/js/autocomplete.js#L71
-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training