2016-12-07 19:04 EST

View Issue Details Jump to Notes ] Wiki ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0012991mantisbtapi soappublic2013-04-06 08:22
Assigned Torombert 
PriorityhighSeveritymajorReproducibilityhave not tried
Product Version 
Target Version1.2.6Fixed in Version1.2.6 
Summary0012991: mc_filter_get_issues returns incorrect results for page_number > page_count
Description(Stemming from a discussion at http://jira.codehaus.org/browse/SONARPLUGINS-1163 )

The filter API assumes that if the requested page number is larger than the last page number, the request page number becomes the last page number. This means that if I request page 4 for a filter which has 2 pages, I will get the second page.

For the SOAP API this means that if a filter returns a number of issues which divides with the request issues per page, the last page will forever loop at the maximum number of rows. E.g.:

- filter returns 400 issues
- rows per page is set to 100
- client verifies if the number of rows is < 100 to break the invocation

When page 0000004 is requested, there will be 100 issues. When page 0000005 -> infinity are requested, those same issues will be returned, and the client will never break out of the loop. The SOAP API code needs to be adjusted to return zero, rather than the last page's issues when the page number is out of bounds.
TagsNo tags attached.
Attached Files

related to 0015721closedgrangeway Functionality to consider porting to master-2.0.x 



jer (reporter)

Last edited: 2011-05-11 14:51

View 2 revisions

I also discovered this scenario.
If you have 300 issues (100 per page)
the first page containq issue 1 to 100,
second page 101 to 200
third page 201 to 300
fourth page 201 to 300 (and not 0 issue)
fifth page 201 to 300 (and not 0 issue)
.... so on in infinite loop.

Is it possible to retrieve the number of pages available?



rombert (developer)

It's not possible right now to retrieve the number of pages, but there is a feature request for that ( bug 0008656 ). Unfortunately it needs a breaking change to the WSDL to be done right so it's likely going to be 1.3.x only.


grangeway (reporter)

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

+Related Changesets

-Issue History
Date Modified Username Field Change
2011-05-11 07:27 rombert New Issue
2011-05-11 07:27 rombert Status new => assigned
2011-05-11 07:27 rombert Assigned To => rombert
2011-05-11 14:48 jer Note Added: 0028770
2011-05-11 14:51 jer Note Edited: 0028770 View Revisions
2011-05-11 15:08 rombert Note Added: 0028771
2011-05-19 17:24 rombert Changeset attached => MantisBT master 7b763277
2011-05-19 17:24 rombert Changeset attached => MantisBT master-1.2.x c70ff523
2011-05-19 17:24 rombert Resolution open => fixed
2011-05-19 17:24 rombert Fixed in Version => 1.2.6
2011-05-19 17:24 rombert Status assigned => resolved
2011-05-19 17:24 rombert File Added: mylyn/context/zip-20110520122434.zip
2011-07-26 09:53 jreese Status resolved => closed
2013-04-05 17:57 grangeway Status closed => acknowledged
2013-04-05 17:57 grangeway Note Added: 0036437
2013-04-05 18:09 grangeway Relationship added related to 0015721
2013-04-06 03:43 dregad Status acknowledged => closed
2013-04-06 07:22 grangeway Status closed => acknowledged
2013-04-06 08:22 grangeway Status acknowledged => closed
+Issue History