View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0025102 | mantisbt | api rest | public | 2018-12-20 08:00 | 2019-03-16 20:20 |
Reporter | eternalstorms | Assigned To | community | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 2.18.0 | ||||
Target Version | 2.20.0 | Fixed in Version | 2.20.0 | ||
Summary | 0025102: /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. 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. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
or am I using the API in a wrong way? |
|
The output is paged, you have to submit multiple requests
Does this fix your issue? |
|
is there a limit to page_size? for testing purposes, I just use page_size=100000 - might that be the issue? |
|
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 |
|
I just did some more testing - I do strongly believe it has to do with the Filter I've set in the Web UI. |
|
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? |
|
I recommend to upgrade to 2.19.0 as a first step. Independent from that, do you have installed any plugins or did you change any original source of Mantis? |
|
my install of MantisBT is vanilla - no plugins. |
|
upgraded to 2.19.0 today, same issue. 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. |
|
Strange, not sure what I tried before, but I am now able to reproduce the issue |
|
That's because the call chain is: $t_issues = mc_project_get_issues('', '', $t_project_id, $t_page_number, $t_page_size ); So issue retrieval always returns filtered results. And if no custom filter is supplied, a default/current is used. A 'hotfix' (1) might be: [1] IMHO a 'bugs_api' (with applied filters, if requested) would be a better approach. |
|
alternate suggestion (I'm not at all familiar with the MantisBT code base, this is just food for thought) : |
|
I am a bit astonished as the function is also used in SOAP API since many years. |
|
we can look. I think that changes in that function were made to keep the same behaviour, but let's make sure. |
|
Seems like the relevant changes in filter_api predates the rest api, and i can't easily test soap api at the moment.
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) |
|
But rest/soap has an explicit param 'filter_id' to request a filtered issue list. So internally using 'filter_get_bug_rows', which implicitly |
|
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. |
|
MantisBT: master 4cc687a9 2019-02-11 11:50 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 |