Edgewall Software
Modify

Opened 12 years ago

Last modified 12 months 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: query system Version: devel
Severity: normal Keywords:
Cc: osimons Branch:
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 12 years ago.
Adds begins with filter option.

Download all attachments as: .zip

Change History (11)

comment:1 by Christian Boos, 12 years ago

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 by Christian Boos, 12 years ago

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.

by Christian Boos, 12 years ago

Attachment: ticket5979-base.diff added

Adds begins with filter option.

comment:3 by Christopher Lenz, 12 years ago

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.

in reply to:  3 ; comment:4 by Christian Boos, 12 years ago

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?

in reply to:  4 comment:5 by Christopher Lenz, 12 years ago

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 by Christian Boos, 12 years ago

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 by osimons, 11 years ago

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 by leandor@…, 10 years ago

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 by Ryan J Ollos, 4 years ago

Owner: Jonas Borgström removed

comment:10 by Jun Omae, 12 months ago

Component: ticket systemquery system
Keywords: query removed

Modify Ticket

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

Add Comment


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