Edgewall Software
Modify

Opened 11 years ago

Last modified 3 years ago

#5979 new enhancement

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

Reported by: asloan12@… Owned by:
Priority: normal Milestone: next-major-releases
Component: ticket system Version: devel
Severity: normal Keywords: query
Cc: osimons
Release Notes:
API Changes:

Description

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

Attachments (1)

ticket5979-base.diff (425 bytes ) - added by Christian Boos 11 years ago.
Adds begins with filter option.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by Christian Boos

Component: generalticket system
Keywords: query added
Milestone: 0.11.10.11
Summary: Add contains option to filters with drop-downs in custom queryAdd more option to filters with drop-downs in custom query

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.

Changed 11 years ago by Christian Boos

Attachment: ticket5979-base.diff added

Adds begins with filter option.

comment:3 Changed 11 years ago by 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.

comment:4 in reply to:  3 ; Changed 11 years ago by 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?

comment:5 in reply to:  4 Changed 11 years ago by 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”

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

comment:6 Changed 11 years ago by Christian Boos

Milestone: 0.110.12

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.

comment:7 Changed 10 years ago by osimons

Cc: osimons added

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.

comment:8 Changed 9 years ago by 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

comment:9 Changed 3 years ago by Ryan J Ollos

Owner: Jonas Borgström deleted

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.