Add more option to filters with drop-downs in custom query

[asloan12@…]

Adding a "contains" option to filters with drop-downs in custom query would be really helpful. The hard part is that it would have to ignore the drop-down and use a text input field. It is really necessary for people overloading the Component field, due to the fact we don't have component/subcomponent capability.

ie. How do you search for all of component "blob" when your choices are "blob: bit", "blob: bot", "blob: bat", "thingie: subdodad"?

[cboos]

I consider this to be a first step in support for sub-components.

As a second step, we could imagine some javascript tricks to "split" the original <select> filled with all the hierarchical components into a first <select> containing only the toplevel entries. Upon selection of an entry which is an intermediate one, another <select> is shown containing the sub-entries, and so on.

[cboos]

attachment:ticket5979-base.diff adds begins with instead of contains.

This make sense with the support for hierarchical components, e.g. when you have:

• version control
• version control/log view
• version control/changeset view
• version control/browser view

selecting: Component begins with version control will give you all the tickets for those 4 components.

[cboos]

Adds begins with filter option.

[cmlenz]

I can see the need for this (basically only pseudo-hierarchical ticket field enums), but it still smells fishy.

Do I understand the patch correctly that you still get a select box, so you basically need a hierarchy with intermediate nodes for this feature to make any sense?

In that case I'm -1. I'd be okay with the change if:

1. you'd get a select box only for “is” and “is not”
2. you'd get all the matching modes already available on text fields, i.e. also “ends with” etc.

[cboos]

Replying to cmlenz:

I can see the need for this (basically only pseudo-hierarchical ticket field enums), but it still smells fishy. Do I understand the patch correctly that you still get a select box, so you basically need a hierarchy with intermediate nodes for this feature to make any sense?

As it stands, yes.

In that case I'm -1.

Sad... but I can improve the patch to basically detect if there are actually such intermediate nodes, and only add the begins with if that's the case.

I'd be okay with the change if: 1. you'd get a select box only for “is” and “is not” 2. you'd get all the matching modes already available on text fields, i.e. also “ends with” etc.

Sorry, I don't understand your alternative approach. Can you clarify?

1. is what we currently have, so no change.
2. does this imply using a text field instead of a select? In all cases?

[cmlenz]

Replying to cboos:

Sad... but I can improve the patch to basically detect if there are actually such intermediate nodes, and only add the begins with if that's the case.

That's even worse, as you'd be adding code to support the encoding of hierarchy in component names.

I object to encouraging the creation of such hierarchies, while providing nothing but an isolated hack in a single place to actually support it. This would open a can of worms: people will get the impression that such hierarchies are officially supported, and will want to see it extended and provided in other places, too (tree view in admin, anyone?)

I'd be okay with the change if: 1. you'd get a select box only for “is” and “is not” 2. you'd get all the matching modes already available on text fields, i.e. also “ends with” etc.

Sorry, I don't understand your alternative approach. Can you clarify? 1. is what we currently have, so no change.

Yeah, but your patch would add “begins with”

2. does this imply using a text field instead of a select? In all cases?

No, only for those cases other than “is” and “is not”. Which means we'd need to change the input dynamically depending on the match mode. And maybe add some AJAX autocompletion for kicks (which might actually be nice for all query text fields).

Taking a step back, is it not true that you can already do beginswith matching using query links and the TicketQuery macro? Personally I think that is enough for our use case for the time being (i.e. 0.11).

[cboos]

Ah, I understand what you meant with your points 1. and 2: it was about dynamically adapting the filter value field, using a <select> for is and is not, changing that to a text input field for the other modes begins with, ends with and contains.

In this case, the whole thing would probably be better done at the Javascript level.

cmlenz:

I object to encouraging the creation of such hierarchies, while providing nothing but an isolated hack in a single place to actually support it. This would open a can of worms: people will get the impression that such hierarchies are officially supported, and will want to see it extended and provided in other places, too (tree view in admin, anyone?)

Well, actually I planned support for that in two places: here for querying, and the suggested "hack" from comment:1 for setting the field. I think this would work well for component hierarchies of any depth (#548). A tree display in admin mode could eventually be fancy or useful(?) but in no way necessary to handle this.

As you said, we can probably just use the TicketQuery for now. So I post-pone this until I have something more comprehensive to propose.