View Issue Details

IDProjectCategoryView StatusLast Update
0013902mantisbtapi soappublic2019-12-13 18:06
Reporterlibregeek Assigned Todregad  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status closedResolutionno change required 
Summary0013902: SOAP method to retrieve User ID
Description

Here is the use case:
We have a custom reporting application which uses the SOAP API. Currently this application uses mc_project_get_issues() to retrieve the issues per project and then by reporter. There are hundreds of issues in each project and each issue in turn has numerous notes added. Since mc_project_get_issues() fetch the entire data, we are planning to switch to mc_project_get_issue_headers() which retrieve only the essential data. However, mc_project_get_issue_headers() has only reporter_id which prevents us to aggregate issues based on reporter.

So it would be nice to have an API which returns the user_id of the reporter which can be used to filter results from mc_project_get_issue_headers.

This can be easily implemented since there is already mci_get_user_id() in soap/mc_api.php which returns the user_id.

TagsNo tags attached.

Relationships

duplicate of 0013445 closedvboctor Add mc_login() for login and to return user data 

Activities

vboctor

vboctor

2012-06-16 19:29

manager   ~0032113

Last edited: 2012-06-18 01:33

View 2 revisions

I'm re-opening this since the implementation for the related issue only tackled this problem for the logged in user. For the other scenario, here are some thoughts:

  1. If we are to provide mc_user_get() - who would have the right to get such information? We can make it so everyone can, but limit access to parts of this information like email address to the same level enforced by the web interface.

  2. Assuming we provided such API, the client will still have to issue N calls to get the information for the users that it has ids for. Don't we need a batch version of such API?

  3. For the methods that return references to users, shouldn't they be using ObjectRef to such users? This would include the user id and name (not full name / email). If we implement the batch get, then we may not necessarily need to change ids to objectrefs (hence, saving memory).

  4. Should we support passing in ObjectRef so that the client can retrieve information about a user using its id or name?

rombert

rombert

2012-06-18 03:36

reporter   ~0032115

  1. +1 for same level as enforced by the web UI
  2. the _get_issue_headers methods return ids, while the _get_issues ones return ObjectRefs . I think it's safe to keep it like this.

I'm going to leave 2,4 to the reporter.

dregad

dregad

2019-12-03 10:51

developer   ~0063186

We are resolving this issue as "no change required", because it was reported against an old version of MantisBT which is no longer supported.

Should the requirement not be covered by REST API or recent versions of SOAP API, do not hesitate to reopen the issue.

Issue History

Date Modified Username Field Change
2012-02-16 04:29 libregeek New Issue
2012-02-16 04:41 rombert Target Version => 1.3.0-beta.1
2012-02-16 04:41 rombert Description Updated View Revisions
2012-06-02 01:22 vboctor Relationship added duplicate of 0013445
2012-06-02 01:22 vboctor Status new => resolved
2012-06-02 01:22 vboctor Resolution open => duplicate
2012-06-02 01:22 vboctor Assigned To => vboctor
2012-06-16 06:36 atrol Target Version 1.3.0-beta.1 =>
2012-06-16 06:36 atrol Description Updated View Revisions
2012-06-16 19:26 vboctor Assigned To vboctor =>
2012-06-16 19:26 vboctor Status resolved => feedback
2012-06-16 19:26 vboctor Resolution duplicate => reopened
2012-06-16 19:29 vboctor Note Added: 0032113
2012-06-18 01:33 vboctor Note Edited: 0032113 View Revisions
2012-06-18 03:36 rombert Note Added: 0032115
2019-12-03 10:51 dregad Assigned To => dregad
2019-12-03 10:51 dregad Status feedback => resolved
2019-12-03 10:51 dregad Resolution reopened => no change required
2019-12-03 10:51 dregad Note Added: 0063186
2019-12-13 18:06 atrol Status resolved => closed