View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0027489 | mantisbt | api rest | public | 2020-11-09 12:17 | 2020-11-25 14:20 |
Reporter | wutsdis | Assigned To | atrol | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Product Version | 2.24.0 | ||||
Summary | 0027489: REST API Returns Only 50 Issues | ||||
Description | Hello, not sure if this is a bug or intended but it is very annoying and I've already lost a day+ trying to work around the problem. There seems to be some hardcoded limit for the max issues to be returned with a get call to the API, I've tried it with the bellow requests and it always gives up to 50. As per the comment from https://documenter.getpostman.com/view/29959/mantis-bug-tracker-rest-api/7Lt6zkP?version=latest#73397753-1560-a5cb-45f0-e0ce0194ceca I'm not sure if that is related to it at all but "The number of issues to return per page. Default is 50 but overridable by configuration." I've tried saving a new filter, just for a single project, that shows 1000 issues. Again works as expected on the webpage but when I call the new filter from the API - only 50 issues. Just for the sake of it I tried some stuff like "/api/rest/issues?page_size=1000?filter_id=123" or "/api/rest/issues?project_id=123?page_size=1000" hoping it works and maybe it isn't documented but there isn't such functionality. My use case is that I want to get a global filter we have hiding the "resolved (And Above)", thus showing only all open bugs, so I can count them per project+subprojects. Or check the resolved/closed for the day per project from the API. This is partially achieved by the https://github.com/mantisbt-plugins/ApiExtend but after installing it, I get error 500 on its config page "/plugin.php?page=ApiExtend/config". I cannot post an issue on the GitHub page, for some reason, it doesn't have an issues page. I tried getting a list with all of the issues concerning the day, but when the filters don't work it's a big chore because we have a lot of projects with thousands of issues, which get mixed in the results and I have to get "/api/rest/issues?page_size=12000" then filter them per project from the response. I actually did it by iterating over 3 pages of 7000 issues and adding the results "/api/rest/issues?page_size=7000&page=3" because I hit some kind of a limit (timeout, request size or serverside something maybe) if I try a bigger number than 12000 page size. | ||||
Additional Information | Site Information | ||||
Tags | No tags attached. | ||||
Eureka! I feel dumb now, just after posting this, I decided to try with an ampersand and it worked - /api/rest/issues?project_id=37&filter_id=100&page_size=1000 |
|
Such kind of query strings (separated by ? from the URL, parameters separated by &), are more or less standard Do you agree we can close this issue? |
|
It's right there in the example on the right-hand side... |
|
Yes, but was not obvious for me that it worked for anything else than pages. Maybe it's just me, idk what to say. Sorry for the bother. :| |
|