View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025515||mantisbt||api rest||public||2019-02-24 16:36||2019-03-16 20:20|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||2.20.0||Fixed in Version||2.20.0|
|Summary||0025515: Simple and Advanced filters are not consistent for handling sub-project issues|
Simple filter for project X, includes all its sub-project issues.
This issue was raised out of the following PR:
|Tags||No tags attached.|
I don't think you understood what i posted there:
For both "simple" and "advanced" filters, the subprojects are always included when a project_id is not explicitly set in the filter
This is not supported, you cannot set it in the web ui, and a "simple" filter ignores the project property
By design, this is expected
We can talk about the future of this simple/advanced convention (0020883), but the issue with PR1464 is a regression on a previously consistent behavior.
@cproensa I try to understand, what change in 4cc687a is actually the regression.
And while we are on this.
as tested in the PR:
Before the PR, in both cases the result always includes subprojects:
I'm not sure of what is the expected behavior, probably the same as you said: do not include subprojects unless requested, but i dont have much experience with the soap/rest api.
The advanced filter have two main differences from simple filters:
I agree that this is a bad design, and will be fixed asap (which in mantis dev times is still uncertain time...)
Depending on the answer to what is the expected api result, as explained in the PR:
@cproensa ok, I got your point.
The intent of the PR was: Return all issues of the project (even the closed ones), but not
That could be achieved by enforcing filter type 'SIMPLE', if a project id is set. I don't
And regarding the API, at least I want an option to include/exclude subprojects issues.
I agree. The discussion about what the api should do as consistent behavior, and if there should be an additional parameter for explicitly including subprojects, is better suited as a separate work.
I don't like either. But don't pay too much relevance to that. As soon as the filters can be fixed/redesigned, this part of the code will be cleaned too.
As for the intention on your original issue:
sorry for the inconvenience
MantisBT: master 2d88283d
Committer: dregad Details Diff
|Fix minor regression with PR 1464
When defining a standard filter that returns "any" issue, don't specify the
project id. Advanced and simple filters both works in the same way,
regarding inclusion of subprojects, as long as the project_id property
is not filled explicitly.
Prevous to PR1464, the api would include subprojects always, but after
the PR, it would have different behaviour if, for example, having
configured $g_view_filters = ADVANCED_ONLY
|mod - core/filter_api.php||Diff File|