Extending tickets autocomplete

RT Developers
1

Hi,

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

  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

Is one of the solutions something that can be integrated into core?
Are there other solutions?

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.

Chris

2

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

  1. 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.

  • Alex
3

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.

  1. 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]

[2]