View Issue Details

IDProjectCategoryView StatusLast Update
0025102mantisbtapi restpublic2019-03-16 20:20
Reportereternalstorms Assigned Tocommunity  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version2.18.0 
Target Version2.20.0Fixed in Version2.20.0 
Summary0025102: /api/rest/issues endpoint supposedly returns all issues, but doesn't
Description

Both for a specific project, as well as for all projects, the issues returned are based on some sort of filter, instead of returning, as expected, all issues (resolved, unresolved, closed, acknowledged, new, etc)

When calling this API, I expected to receive all issues for either all projects, or a specified project, not only a subset of them.
Even the documentation states "GET - Get all issues" or "GET - Get issues for a project - Get all issues for the specified project"

However, not all issues are returned, only a subset of them, presumably based on either a set filter in Mantis, or some other criteria.

Currently, I don't see a way to receive, for example, closed or new issues - I only ever receive assigned ones. I can't even receive resolved issues this way.

Additional Information

Since I can specify a filter with these calls (filter_id = <id of filter or unassigned, assigned, monitored, etc>), not specifying a specific filter (omitting the field entirely) should return all issues, unfiltered.

TagsNo tags attached.
Attached Files

Relationships

related to 0021996 feedback Service mc_project_get_issues not return closed issues 
related to 0025515 closedcproensa Simple and Advanced filters are not consistent for handling sub-project issues 

Activities

eternalstorms

eternalstorms

2019-01-21 13:54

reporter   ~0061261

or am I using the API in a wrong way?

atrol

atrol

2019-01-21 15:57

developer   ~0061265

Last edited: 2019-01-21 15:58

The output is paged, you have to submit multiple requests

GET http://.../api/rest/issues?page_size=10&page=1
GET http://.../api/rest/issues?page_size=10&page=2

Does this fix your issue?

eternalstorms

eternalstorms

2019-01-22 07:38

reporter   ~0061270

is there a limit to page_size? for testing purposes, I just use page_size=100000 - might that be the issue?

atrol

atrol

2019-01-22 08:14

developer   ~0061271

I didn't try, but I assume you might get issues depending on various PHP settings when fetching a lot of issues in one go, e.g. http://php.net/manual/en/ini.core.php#ini.memory-limit

eternalstorms

eternalstorms

2019-01-23 11:26

reporter   ~0061278

I just did some more testing - I do strongly believe it has to do with the Filter I've set in the Web UI.
Because when I choose [Reset filter] for both the upper and the lower popup field, then the API will return all issues, not just the ones matching that filter I had set.
Is there any way around that?

eternalstorms

eternalstorms

2019-01-28 17:38

reporter   ~0061314

I do use the project_id parameter, though - does that change anything? are issues for projects based on the filter the user has set up for that project?

atrol

atrol

2019-01-30 14:44

developer   ~0061334

I recommend to upgrade to 2.19.0 as a first step.
As I was not able to reproduce your issue, this might fix it or at least will make it easier to search the root cause of the bug.

Independent from that, do you have installed any plugins or did you change any original source of Mantis?

eternalstorms

eternalstorms

2019-01-31 03:30

reporter   ~0061347

my install of MantisBT is vanilla - no plugins.
I'll try upgrading to 2.19.0 as soon as I get a chance.

eternalstorms

eternalstorms

2019-02-06 13:51

reporter   ~0061424

Last edited: 2019-02-06 13:57

upgraded to 2.19.0 today, same issue.
api/rest/issues?project_id=<id> (using the paged mechanism) only returns issues matching the filter set beneath the blue filter bar for that project in the web ui (see attached screenshot).

the expected result would be that all issues are returned (from closed to new), however, in the case of the screenshot, only issues below resolved status are returned.

no plugins, no custom code.

atrol

atrol

2019-02-06 15:39

developer   ~0061425

Strange, not sure what I tried before, but I am now able to reproduce the issue
e.g https://mantisbt.org/bugs/api/rest/issues?project_id=11 should always deliver 50 out of 52 issues, but I get the issues based on latest filter set in UI.

obmsch

obmsch

2019-02-06 18:52

reporter   ~0061426

That's because the call chain is:

$t_issues = mc_project_get_issues('', '', $t_project_id, $t_page_number, $t_page_size );
$t_rows = filter_get_bug_rows( $p_page_number, $p_per_page, $t_page_count, $t_bug_count, null, $p_project_id );
filter_get_bug_rows( &$p_page_number, &$p_per_page, &$p_page_count, &$p_bug_count, $p_custom_filter = null, $p_project_id = null, $p_user_id = null, $p_show_sticky = null ) {

So issue retrieval always returns filtered results. And if no custom filter is supplied, a default/current is used.
That's ok with WebUI, but not with rest/soap where an explicit filter is supplied if needed at all.

A 'hotfix' (1) might be:
Instead of passing 'null' for "$p_custom_filter" in 'filter_get_bug_rows', pass 'Filter_Any' (TBD).

[1] IMHO a 'bugs_api' (with applied filters, if requested) would be a better approach.

eternalstorms

eternalstorms

2019-02-07 02:02

reporter   ~0061427

Last edited: 2019-02-07 02:02

alternate suggestion (I'm not at all familiar with the MantisBT code base, this is just food for thought) :
you have these pre-defined filters (assigned, unassigned, monitored, reported - see 0022790), how about adding a fifth, "all", or "nofilter", or something like that

atrol

atrol

2019-02-07 02:30

developer   ~0061429

I am a bit astonished as the function is also used in SOAP API since many years.
So this never worked before or there is a regression, maybe caused by changes in filter code.
I don't have time to have a deeper look at this, maybe @cproensa can comment.

cproensa

cproensa

2019-02-07 02:46

developer   ~0061430

So this never worked before or there is a regression, maybe caused by changes in filter code.
I don't have time to have a deeper look at this, maybe @cproensa can comment.

we can look. I think that changes in that function were made to keep the same behaviour, but let's make sure.

cproensa

cproensa

2019-02-07 04:18

developer   ~0061432

Seems like the relevant changes in filter_api predates the rest api, and i can't easily test soap api at the moment.

And if no custom filter is supplied, a default/current is used

I think that the intention of this function has always been that. See filter_get_bug_rows(), filter_get_bug_rows_filter()

However, there is some point where filter related changes fixed the retrieval of persistent filters, so it actually gets the "currently applied" filter for each project, instead of failing in most cases (and fallback to a default)
May be that prior to that change, the api returned only issues for a "default" filter, not "current", so this isse was not that easily noticed.
And in any case, i think falback to a "default" filter, and not managing the hide-sataus properties (like is done in any other part of the code) is a long standing issue: 0021996 0022001 0010969 ...

obmsch

obmsch

2019-02-07 05:08

reporter   ~0061433

But rest/soap has an explicit param 'filter_id' to request a filtered issue list. So internally using 'filter_get_bug_rows', which implicitly
applies a default/current filter, is the problem, if a request for all issues is made.

cproensa

cproensa

2019-02-07 05:46

developer   ~0061434

But rest/soap has an explicit param 'filter_id' to request a filtered issue list. So internally using 'filter_get_bug_rows', which implicitly
applies a default/current filter, is the problem, if a request for all issues is made.

Is a established code procedure, when requesting a filter to get explicitly all issues, to reset the hide-status property. This is done in my-view, summary, etc to work around that "default". I think it is not an ideal workflow, but needs time and care to be redesigned.
To be in line with the rest of the application, the soap/rest api should also manage it internally when creating system filters, regardless of what the published behavior of the api is.

obmsch

obmsch

2019-02-11 17:18

reporter   ~0061480

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

Related Changesets

MantisBT: master 4cc687a9

2019-02-11 11:50

obmsch

Committer: vboctor


Details Diff
Fix not all issues returned via REST API

- Add FILTER_STANDARD_ANY
- Add filter_create_any() to filter_api
- Handle FILTER_STANDARD_ANY in filter_standard_get
- Use in issues_rest, if the request doesn't contain a filter_id

Fixes 0025102
Affected Issues
0025102
mod - api/rest/restcore/issues_rest.php Diff File
mod - api/soap/mc_filter_api.php Diff File
mod - core/constant_inc.php Diff File
mod - core/filter_api.php Diff File