View Issue Details

IDProjectCategoryView StatusLast Update
0021996mantisbtapi soappublic2019-02-06 15:30
Reporterrquintana Assigned To 
Status feedbackResolutionopen 
Summary0021996: Service mc_project_get_issues not return closed issues

//referencia a webservice mantis
var serv = new MantisFisConnect.MantisConnectPortTypeClient();
var resultIssues = serv.mc_project_get_issues(user, userPass, proyectoId, page.ToString(), "100");

In c# mc_project_get_issues do not return closed issues, only issues thar not closed.


TagsNo tags attached.


related to 0022001 assigneddregad FilterTest::testGetProjectClosedIssues should fail but does not 
related to 0010969 closedrombert The issue closed can not be found by mc_project_get_issues API? 
related to 0025102 closedcommunity /api/rest/issues endpoint supposedly returns all issues, but doesn't 




2016-11-30 19:49

developer   ~0054647

@rombert this should work according 0010969, but it seems you have to set $g_hide_status_default = META_FILTER_NONE; for it 0016889:0039227

I would expect that the test fail.



2016-12-01 09:18

developer   ~0054652

Got email from rombert, he will check next week



2016-12-01 11:38

developer   ~0054655

For the record, here is the (confirmed) reason the unit test fails 0022001



2016-12-01 12:01

developer   ~0054657

This behavior is confirmed in both 1.3.x and master branches.

See PR for the fix of the unit test



2016-12-03 16:51

reporter   ~0054669

I think the current behaviour should stay as it is, since it's been long done this way and we risk breaking existing integrations.

There are at least two ways of retrieving all issues:

  • setting $g_hide_status_default = META_FILTER_NONE, as @atrol mentioned
  • using the the mc_filter_get_issues SOAP API call, which can be backed by a custom filter which returns all issues

Using the mc_filter_search_issues SOAP API call might also work, but I did not check it.

@rquintana, would that work for you?



2016-12-05 06:00

developer   ~0054675

@rombert, thanks for the feedback.

I agree we should be careful not to break existing applications relying on a behavior of the API.

That being said, the current behavior of mc_project_get_issues() is somewhat confusing, as one's expectation is that it would indeed retrieve all issues (it was apparently also the case for you, since you initially wrote the test script along these lines).

If the decision is the status quo, I would propose that

  1. we clearly document the limitation of mc_project_get_issues(), referencing the alternative options you described
  2. if really needed, provide a new API mc_project_get_all_issues() that retrieves all issues regardless of $g_hide_status_default setting.

With regards to amending the test script as per your comment [1]

My preference would be for keeping the current behaviour [...] and if we
decide to go for that solution we should adjust the test to pass.

To achieve that, would you recommend that the test takes $g_hide_status_default into consideration ? Or that we just drop the testGetProjectClosedIssues case entirely ?




2017-01-09 18:02

developer   ~0055007

ping @rombert for

To achieve that, would you recommend that the test takes $g_hide_status_default into consideration ? Or that we just drop the testGetProjectClosedIssues case entirely ?



2017-01-17 14:39

reporter   ~0055187

Last edited: 2017-01-17 14:40

View 3 revisions

Thanks for the ping @atrol and sorry for the delay. I had a quick conversation with @dregad about this and here's my take in on the situation

  • Backwards compatibility is important to me, and this being an API which is consumed by 3rd party clients any behaviour change would have quite some impact. So I would get the function to take $g_hide_status_default into consideration.
  • There's a new API function for searching for issues - the mc_filter_search* functions. Given that, users can perform any kind of searches, not just the predefined ones using mc_filter_get* and mc_project_get* so I don't think we need to add new methods.

Issue History

Date Modified Username Field Change
2016-11-30 13:54 rquintana New Issue
2016-11-30 19:49 atrol Note Added: 0054647
2016-11-30 19:50 atrol Status new => acknowledged
2016-12-01 08:28 dregad Relationship added related to 0010969
2016-12-01 09:18 atrol Note Added: 0054652
2016-12-01 11:38 dregad Note Added: 0054655
2016-12-01 11:38 dregad Relationship added related to 0022001
2016-12-01 12:01 dregad Status acknowledged => confirmed
2016-12-01 12:01 dregad Note Added: 0054657
2016-12-03 16:51 rombert Status confirmed => feedback
2016-12-03 16:51 rombert Note Added: 0054669
2016-12-05 06:00 dregad Note Added: 0054675
2017-01-09 18:02 atrol Note Added: 0055007
2017-01-17 14:39 rombert Note Added: 0055187
2017-01-17 14:39 rombert Note Edited: 0055187 View Revisions
2017-01-17 14:40 rombert Note Edited: 0055187 View Revisions
2019-02-06 15:30 atrol Relationship added related to 0025102