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

[Christian Boos]

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.

[Christian Boos]

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.

[Christian Boos]

Adds begins with filter option.

[Christopher Lenz]

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.

[Christian Boos]

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?

[Christopher Lenz]

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

[Christian Boos]

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.

[osimons]

Related to #5526.

#7258 suggested the alternative of the user in custom query being able to switch the field from select to text as needed, and thereby supporting the full range of 'startswith', 'contains' and so on.

[leandor@…]

We are in great need of this feature, at least until support for component hierarchy or real multiproject support is added.

The proposed change of using only text entry boxes plus a popup that appears as you type (there's some plugin that already lets you do that for the Owner field: We are using it… ) and lets you choose the correct entry would work OK for all cases, I think.

Without the need for special conditions and/or different input entry metaphors…

In any case, added my mail to the CC list :)

Cheerz, leandro