Skip to main content
G
gschwarz1-Visitor
1-Visitor
November 14, 2017
Question

Value pattern or contains for pick fields in a query

  • November 14, 2017
  • 1 reply
  • 2044 views

My problem is, that I'd like to create some queries that contain a list of items with a range of values in a specific field, which is a pick field. I could specify this by selecting all desired values in that. But if the pick list gets extended the queries will need manual updates every time the list changes - if the value matches the range. The definition of a specific query for the field and then using it as a sub-query for the other queries would reduce the manual work, but I'd still depend on the information, that the field had changed and a manual update of a query.

 

Example:

The pick list field could be 'release' with values [v1.0, v1.1, v1.2, v1.2.1, v2.0, v2.1, v2.2, v2.4, v2.5, v3.0, ...].

Now I'd like to filter all items for release v1.x.y. When I now select all the relevant releases. If 'v1.3' would be added I'll have to modify the list in the filter.

 

Is  there a way to specify '(field["release"] contains "v1."' or maybe some RegEx 'field["release"]="v1\..*"' to filter the list? So I would not depend on getting the information, that the field had been changed and the query would automatically contain the new value in the pick list, when it matches the selection.

    1 reply

    V
    VolkerEckardt17-Peridot
    17-Peridot
    December 10, 2017

    Hello Günter,

    there are some ideas coming into my mind:

     

    1/ Releases as Items (not pick field)

    Releases as such should rather become an item. Then you can add more filter attributes, e.g. release description, release content, release responsible etc.

    Using items will give you almost any advantage that you need to group them in any way (as you want).

    To link the release item to the base item itself you can use a relationship or an IBPL field.

     

    2/ Grouping for Pick values

    The only build-in option I can think of are range values. But this requires that you have for any value a rangeable ID set. For example, v1.0 should have then 100 as ID, v1.1 = 110, v2.1 = 210 etc.

    The range you can build then is 0-199 = v1, 200-299 = v2, 300-399= v3 etc.

    But, assuming you already have the pick values and IDs set differently, its not possible to re-number them. So this  approach is only good when you start fresh. 

     

    3/ Use a Trigger to fill a new Group Value

    This option will provide you with the highest flexibility. Write a PRE trigger and let him determine the range value automatically. You need another field to store the result, e.g. "Release Group". If for example the Release value is v1.1, then the Trigger will write a v1 into the "Release Group" field.  The only downside of this approach is that you need to update already existing items. Hopefully you can manage this.

     

    Personally I would take option 1 (and have done it already). This gives you the flexibility, and also the most reporting options. 

     

    Hope this helps

    Volker

    Terms & ConditionsAccessibility statement