Overview
Allow to search on fields (outside semantics & "Always There Fields") without too much overhead in the query definition or column selection.
Apply "duck typing" principle: if it has the same name and has a compatible type, let's assume it's the same thing.
Compatible types definition:
- All numerics (initial_effort could be fload or int): float
- All list with same bind (eg a select box with static values and check box with static values) including open lists
- String and text fields
- Date
- Date time (to be clear: date and date time are not compatible types)
Are excluded of search:
- rank: doesn't make sense to search on this value that is purely internal
- computed fields: as computed fields are computed on display we cannot search on them.
- permission on artifact: cannot be searched on in TQL as of today.
Searches
In the following example we uses the the term exist for a field being in a tracker. The complete definition is:
- The field is technically present in the tracker
- The user who runs the query can read the content of the field
Base rules
When a field exists in ALL trackers of the query
And there is at least one of the field that is not compatible
Then there is an error
When a field exists in SOME trackers of the query
and there is least one of the field that is not compatible
Then there is an error
When a field exists in SOME trackers of the query
and all the fields are compatible
Then the query is performed on the trackers that share the field
Base scenario
Given the query category="foo" on tracker T1, T2
And category exists in T1,T2
And have a compatible definition
Then the query applies on both tracker
Given the query category="foo" on tracker T1, T2
And category exists in T1,T2
And doesn't have a compatible definition
Then the query gives an error: field category is present in T1 and T2 but their types cannot be compared (T1.category = text/md, T2.category = text/html)
Given the query category="foo" on tracker T1, T2
And category only exists in T1
Then the query only applies on T1
Exist rule precision: It means that if category exists in T1 and T2 but the current user can only see it in T1, then the query only applies on T1.
Filter as much as possible
Given the query category="foo" on tracker T1, T2, T3
And no tracker has category as field
Then the query lead to an error: no tracker is matching the query
Given the query category="foo" on tracker T1, T2, T3
And only T1 have category field
the query will apply on T1 only
Given the query category="foo" on tracker T1, T2, T3
And T1 & T2 have category field with compatible definitions (see Overview)
the query will apply on those 2 trackers
Two terms
Given the query category = "foo" and priority = "bar" on tracker T1, T2, T3
And category exists in T1, T2 but not in T3
And priority exists in T3 but not in T1,T2
Then the query gives no tracker is matching the query
Given the query category = "foo" and priority = "bar" on tracker T1, T2, T3
And category exists in T1, T2,T3
And priority exists in T3 but not in T1,T2
Then the query applies only on T3
List fields
List values may not exist in all trackers included in the query. In the same spirit as "duck typing" for fields, we apply the same method for list values:
Given the query list_field = "foo" on trackers T1, T2, T3
And list_field exists in T1, T2 and T3
And the list value "foo" exists in T1, T2 but not in T3
Then the query does not raise an error, and applies only on T1 and T2
Given the query list_field = "bar" on trackers T1, T2, T3
And list_field exists in T1, T2 and T3
And the list value "bar" does not exist in any of the three trackers above
Then the query raises an error that the list value "bar" does not exist
This is the case for list fields bound to static values, to users or to user groups.
Impacts on "single-tracker" TQL expert query
Previously, comparing an integer field with a float value (for example int_field > 3.3) was forbidden and raised an error. This constraint will be lifted. Since integer and float fields are treated as a single "numeric" category in cross-tracker search, we will lift this constraint to ease this work. Both float fields and integer fields will now allow comparisons to float values (3.3)