Vote #77594: Add the possibility to filter issues after Target Version's Status and Due Date - redmineorg-copy202205 - Redmine

編集操作

リンクをコピー

Vote #77594

完了

Add the possibility to filter issues after Target Version's Status and Due Date

Admin Redmine さんが4年以上前に追加. 4年以上前に更新.

ステータス:

Closed

優先度:

通常

担当者:

カテゴリ:

Issues filter_56

対象バージョン:

3.4.0_119

開始日:

2022/05/09

期日:

進捗率:

予定工数:

Redmineorg_URL:

https://www.redmine.org/issues/23215

category_id:

version_id:

119

issue_org_id:

23215

author_id:

107353

assigned_to_id:

comments:

status_id:

tracker_id:

plus1:

affected_version:

closed_on:

affected_version_id:

ステータス-->[Closed]

引用

説明

Currently, we have the possibility to filter issues only after target version name and target version's custom fields (that have the "Used as a filter" checked).

It'll very helpful to have the possibility to filter after target version status (open/locked/closed) and target version due date (effective_date). With these 2 new filters you can cover most of the use cases related to target version.
Some examples:

a query that returns all the issues that are assigned in open versions
a query that returns all the issues that are assigned in versions with due date

The attached patch:

implements these new 2 filters
groups the target version status and target version due date with target version's custom fields under the label Target Version . I wasn't sure that is a good idea to move also the existing target version filter (name) to this group. (attached target_version_group.png)
adds 2 new tests
breaks an existing tests (QueryTest#test_total_by_project_group_for_spent_hours), but I'm not sure how to fix the problem. The respective test have also a to do comment to remove some code after this "issue":https://github.com/rails/rails/issues/21922 is fixed (and is was fixed).

I think that this ticket is related to #21249

journals

--------------------------------------------------------------------------------
Thanks for this patch.

> breaks an existing tests (QueryTest#test_total_by_project_group_for_spent_hours), but I'm not sure how to fix the problem.

This is caused by a Rails bug that was reported here: https://github.com/rails/rails/issues/21922

> The respective test have also a to do comment to remove some code after this issue is fixed (and is was fixed).

This is another issue that will also be fixed in Rails 5.

I'd prefer using a subquery when a filter is applied on version date or status rather that having to do a left join on versions for all queries. Otherwise, we'll have to wait for Rails 5.
--------------------------------------------------------------------------------
Jean-Philippe Lang wrote:
>
> I'd prefer using a subquery when a filter is applied on version date or status rather that having to do a left join on versions for all queries. Otherwise, we'll have to wait for Rails 5.

Thanks for your feedback, it is very useful for me. I'll update the patch next week to use subquries.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
I've updated the patch to avoid the left join on versions for all queries. With the current patch, all the tests pass. I chose to retrieve first the version ids and then make an "fixed_version_id IN ()" condition because it doesn't require to write a custom query. @Jean-Philippe Lang, I'm not sure if this solution is better or not than your proposed one.

--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
I've updated the patch to apply clearly on the current trunk (r15732). Is there anything else I can do in order to have this in 3.4.0? (together with the other changes made on queries).
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
We are also interested by this feature in our company, and I tried it on our test server.

It works well, but there is a remark I would like to make:
In most Redmine filters, using the "Is not" operator includes nulls in the results. For example, if you filter for Target version "is not" and select all versions (multi-selection), you will obtain the same result as with the "None" operator (that is, all not planned issues).

I have the feeling that your filters should do the same.
(something, like:
@nl = operator == "!" ? "#{Issue.table_name}.fixed_version_id IS NULL OR" : ''
"(#{nl} #{sql_for_field("fixed_version_id", "=", version_ids, Issue.table_name, "fixed_version_id")})"@
)
--------------------------------------------------------------------------------
Olivier Houdas wrote:
> In most Redmine filters, using the "Is not" operator includes nulls in the results. For example, if you filter for Target version "is not" and select all versions (multi-selection), you will obtain the same result as with the "None" operator (that is, all not planned issues).

I'm not sure at which filter do you refer because this patch adds the following two new filters:
# *Target Version's Status*: which has the "Is not" operator but your scenario is not possible because versions with status null cannot exist in Redmine. Each version has a status: open, closed or locked.
# *Target Version's Due Date*: The "Is not" operator isn't available for this filter.

Please let me know if I'm wrong.
--------------------------------------------------------------------------------
I refer to both filters, as the Target version field can be null for an issue (not set).
Currently,
# "Target version "is not" (multiple selection of all versions defined) returns all issues which do not have any target version defined
# "Target version status" "is not" "Closed" returns all issues having a target version defined, which have the open or locked status
# "Target version due date" "none" returns all issues which have a target version defined, but for which no due date is defined

My understanding of those conditions would return
# current behaviour of Redmine, unchanged
# all issues with an open or locked target version PLUS all issues which do not have any target version defined
# all issues which have a target version defined with no due date PLUS all issues not having any target version defined

I hope my remark is clearer with those two examples.
(edit: corrected my text as I had mixed two examples into one, making no sense, sorry)
--------------------------------------------------------------------------------
Olivier Houdas wrote:
> I refer to both filters, as the Target version field can be null for an issue (not set).
> Currently,
> # "Target version "is not" (multiple selection of all versions defined) returns all issues which do not have any target version defined
> # "Target version status" "is not" "Closed" returns all issues having a target version defined, which have the open or locked status
> # "Target version due date" "none" returns all issues which have a target version defined, but for which no due date is defined
>
> My understanding of those conditions would return
> # current behaviour of Redmine, unchanged
> # all issues with an open or locked target version PLUS all issues which do not have any target version defined
I've updated the patch in order to include also the issues without target version when the "Is not" operator is used. Attached 3.4.0_filter_after_target_version_status_and_due_date_r15820.patch

> # all issues which have a target version defined with no due date PLUS all issues not having any target version defined
Here I wasn't sure what to do because of the following behaviour:
* add a new custom field for versions ("Start date" for example) having the format set to "date"
* check "Used as a filter"
* repeat your test with "none" operator using the filter "Target version's Start date" and observe that the issues without target version are not included.

Maybe your proposal is the expected behaviour and this is a bug in the Redmine core, but I think that is better to wait for a feedback from Redmine contributors regarding this case.

> I hope my remark is clearer with those two examples.
> (edit: corrected my text as I had mixed two examples into one, making no sense, sorry)
Thanks for your feedback and the detailed explication, now it is clear for me.

Regarding the new patch, I've made some improvements to the tests in order to:
* check also the issues ids returned by these new queries
* check the case with "is not" operator.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Patch committed in r15881 with a few changes, thanks. Filters are named @fixed_version.status@ and @fixed_version.due_date@ instead.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

related_issues

relates,Closed,21249,Ability to filter issues by attributes of a version custom field (e.g. release date)
relates,Closed,30924,Filter on Target version's Status in subproject doesn't work on version from top project
relates,Closed,36824,Allow to filter issues by its version status with shared versions
duplicates,Closed,23855,Target version filter should get an entry 'All open versions'
duplicates,Closed,20197,Filter Issue by attribute of the Version
duplicates,Closed,14164,filter issue list by version status