View Issue Details

IDProjectCategoryView StatusLast Update
0025515mantisbtapi restpublic2019-03-16 20:20
ReportervboctorAssigned Tocproensa 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version 
Target Version2.20.0Fixed in Version2.20.0 
Summary0025515: Simple and Advanced filters are not consistent for handling sub-project issues
Description

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

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

TagsNo tags attached.

Relationships

related to 0020238 new advanced filter search, "current" project inconsistent 
related to 0025102 closedcommunity /api/rest/issues endpoint supposedly returns all issues, but doesn't 

Activities

cproensa

cproensa

2019-02-27 12:05

developer   ~0061593

@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.

obmsch

obmsch

2019-02-27 18:58

reporter   ~0061600

@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).

cproensa

cproensa

2019-02-27 19:24

developer   ~0061601

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
obmsch

obmsch

2019-02-28 18:13

reporter   ~0061606

@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.

cproensa

cproensa

2019-02-28 18:42

developer   ~0061607

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.

cproensa

cproensa

2019-03-02 13:39

developer   ~0061615

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

cproensa

cproensa

2019-03-05 17:01

developer   ~0061638

@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

Related Changesets

MantisBT: master 2d88283d

2019-03-02 13:31:56

cproensa


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

Fixes: 0025515
Affected Issues
0025515
mod - core/filter_api.php Diff File

Issue History

Date Modified Username Field Change
2019-02-24 16:36 vboctor New Issue
2019-02-27 11:31 cproensa Relationship added related to 0020238
2019-02-27 12:05 cproensa Note Added: 0061593
2019-02-27 18:58 obmsch Note Added: 0061600
2019-02-27 19:24 cproensa Note Added: 0061601
2019-02-28 18:13 obmsch Note Added: 0061606
2019-02-28 18:42 cproensa Note Added: 0061607
2019-03-02 13:39 cproensa Note Added: 0061615
2019-03-02 13:40 cproensa Assigned To => cproensa
2019-03-02 13:40 cproensa Status new => assigned
2019-03-02 18:01 dregad Changeset attached => MantisBT master 2d88283d
2019-03-02 18:01 cproensa Status assigned => resolved
2019-03-02 18:01 cproensa Resolution open => fixed
2019-03-02 18:01 cproensa Fixed in Version => 2.20.0
2019-03-02 18:02 dregad Target Version => 2.20.0
2019-03-05 16:56 cproensa Product Version 2.19.0 =>
2019-03-05 16:56 cproensa Fixed in Version 2.20.0 =>
2019-03-05 16:56 cproensa Summary Simple and Advanced filters are not consistent for handling sub-project issues => PR 1464 REST api: Simple and Advanced filters are not consistent for handling sub-project issues
2019-03-05 17:01 cproensa Note Added: 0061638
2019-03-05 17:08 cproensa Relationship added related to 0025102
2019-03-16 20:18 vboctor Category sub-projects => api rest
2019-03-16 20:18 vboctor Fixed in Version => 2.20.0
2019-03-16 20:18 vboctor Summary PR 1464 REST api: Simple and Advanced filters are not consistent for handling sub-project issues => Simple and Advanced filters are not consistent for handling sub-project issues
2019-03-16 20:20 vboctor Status resolved => closed