there are many different usecases. We want to use these numbers in lists, in computations and so on. As an example: How many issues from a specific type with a specific state arethere from week to week. I think some of these usecases could be solved by workarounds or by computations itself, but it would be much easier, if the number of results would be a retrievable value.
If I understand you correctly, do you mean result of a query is not returning total "number" of objects returned in the bottom left corner of GUI? Do you want to add a snapshot or a pictorial representation of idea you want to suggest?
Either by creating a new Field and using Computation expression in the filed (e.g. Query("administrator:All Defects",count())) and then adding this filed to the Item of your interest for generating report.
While creating a report if you use "Computed Fields" from Item Fields tab and add an expression to it e.g. Query("administrator:All Defects",count())
thanks for your hints and it's certainly helpful to use these workarounds in some cases, but i guess not in all cases. Nevertheless it would be usefull to have a more direct access to such data.
Will it be feasible for you to provide a case or a scenarios where you are not able to use the workaround provided above/or it is not useful so that we can consider the missing part for implementation in future release of Integrity.
I have to admit that i didn't really try to use the workarounds for this, but maybe it shows why we would like to have direct access to these numbers: Because Integrity lacks some functionalities in queries itself we have to run sometimes more than one query and aggregate the results afterwards. As an example:
"Show all items with a connected change package, which is created at a specific date, has a member update and belongs to project XYZ"". This is a question which cannot be answered at the moment with ONE query, because integrity is always connecting all filter criterias by OR instead of AND. This behaviour is not configurable (AFAIK there exists a RfC 108414 for this since 2014), so we have to use at least some more specific queries and aggregate the results afterwards.
If i would like t see these results as ONE number in a report, i would have to use your computation in every single query and afterwards i have to use again a computation to aggregate. Maybe i can do these computations alltogether in one computation, but if i have to write code to create a report, i could even use another tool, which is easier to use and could use the API to get the query-results.
