0013902: SOAP method to retrieve User ID - MantisBT

MantisBT

View Issue Details [ Jump to Notes ] [ Wiki ]

[ Issue History ] [ Print ]

ID

Project

Category

View Status

Date Submitted

Last Update

0013902

mantisbt

api soap

public

2012-02-16 04:29

2012-06-18 03:36

Reporter

libregeek

Assigned To

Priority

normal

Severity

feature

Reproducibility

have not tried

Status

feedback

Resolution

reopened

Platform

OS

OS Version

Product Version

Target Version

Fixed in Version

Summary

0013902: 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.

Tags

No tags attached.

Relationships

duplicate of

closed

Add mc_login() for login and to return user data

Notes
(0032113) vboctor (administrator) 2012-06-16 19:29 edited on: 2012-06-18 01:33	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?

(0032115) rombert (developer) 2012-06-18 03:36	1. +1 for same level as enforced by the web UI 3. 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.

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.x
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.x =>
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

MantisBT 1.2.16dev master-1.2.x-05091f5 [^]

Copyright © 2000 - 2013 MantisBT Team

Time: 0.0670 seconds.
memory usage: 2,818 KB