@vboctor

This issue was raised out of the following PR:
https://github.com/mantisbt/mantisbt/pull/1464

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
In PR 1464, by setting an explicit project id, causes a regression that makes the soap/rest api dependant on filter type.
As explained in 0020238, an advanced filter with a specific project id does not include subprojects.

So:

Simple filter for project X, includes all its sub-project issues.

This is not supported, you cannot set it in the web ui, and a "simple" filter ignores the project property

Advanced filter for project X, doesn't include its sub-project issues.

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.

In PR 1464, by setting an explicit project id, causes a regression that makes the soap/rest api dependant
on filter type.

• SOAP/WebUI no change at all, REST only affected, if no filter id is set and only then a new code path is used.
• they were dependant before (default, current) and will be as long as a filter type is implicitly applied.

And while we are on this.
Why does an API consumer get all subprojects issues of the project as well, if he doesn't asks for that explicitly? GetIssues(pid)/GetIssues(pid,includeSubs).

what change in 4cc687a is actually the regression

as tested in the PR:

 `/api/rest/issues?project_id=xxx`
    * If having `$g_view_filters = SIMPLE_ONLY;` returns issues including subprojects
    * If having `$g_view_filters = ADVANCED_ONLY;` returns issues only for project xxx, without subprojects.

Before the PR, in both cases the result always includes subprojects:

• Before, that was consistent, and that's why i say that it was not dependant on filter-view-type
• Before, even if consistent, i'm not saying that was good or bad.

Why does an API consumer get all subprojects issues of the project as well, if he doesn't asks for that explicitly? GetIssues(pid)/GetIssues(pid,includeSubs).

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.

they were dependant before (default, current) and will be as long as a filter type is implicitly applied.

The advanced filter have two main differences from simple filters:

• For selectable options, allows a selection of multiple values (simple filter shows a single-value selection). This affects only web-ui, and a simple filter internally can have parameter with a list of discrete values and will work fine.
• Inclusion of subprojects, the behavior is different, as explained in 0025515:0061593. This affects the internal logic of the filter.

I agree that this is a bad design, and will be fixed asap (which in mantis dev times is still uncertain time...)
The sensible approach is to remove this filter-view-type distinction, and include an explicit flag in the filter to indicate whether subprojects are to be included.
But, until then, we must work around this quirks.

Depending on the answer to what is the expected api result, as explained in the PR:

The way to fix this can be (for always including subprojects)
    * Either, Do not set project_id in the filter, and then the project is applied through "$g_project_override"
    * Or, Explicitly set `_view_type` to simple.

or for never including subprojects:
    * Always set the project_id AND set `_view_type` to advanced

@cproensa ok, I got your point.

The intent of the PR was: Return all issues of the project (even the closed ones), but not
to magically exclude others. That's indeed a regression and should be fixed asap.

That could be achieved by enforcing filter type 'SIMPLE', if a project id is set. I don't
like this approach, because the API shouldn't care about filter type (view) anyway.

And regarding the API, at least I want an option to include/exclude subprojects issues.
so depending on the default (included, excluded), the API consumer either explicitly excludes
or includes them. The latter looks more genuine to me, but I am ok with the former.

The intent of the PR was: Return all issues of the project (even the closed ones), but not
to magically exclude others. That's indeed a regression and should be fixed asap.

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.

That could be achieved by enforcing filter type 'SIMPLE', if a project id is set. I don't
like this approach, because the API shouldn't care about filter type (view) anyway.

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.
My 2nd suggestion: "Do not set project_id in the filter", avoids setting explicitly the view_type (should work with any scenario). So for your concerns, spares you from tinkering with that property.
The project is applied by the filter at runtime, because $g_project_override forces a current project global to the execution of all the api calls.

PR: https://github.com/mantisbt/mantisbt/pull/1473

@vboctor
since we have focused on the specific issue with PR 1464, and this is a fix for something that has not been released,
i have removed "fixed in version" to not appear in changelog.

As for the intention on your original issue:

• There is the related: 0020238 advanced filter search, "current" project inconsistent.
• Regarding the soap/rest api, probably there is a consistency when using the other standard filters: assigned, resolved, etc, where the simple/advanced options produce different results. Please open a new one specific to the rest api.

sorry for the inconvenience