[#JRA-8970] Consider adding a SOAP service to get all users

JIRA

Consider adding a SOAP service to get all users

Created: 08/Jan/06 07:29 PM Updated: 29/Apr/08 03:04 AM

Component/s:

Remote API (SOAP & XML-RPC)

Affects Version/s:

3.4.3

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue is duplicated by:

~~JRA-14880~~ how to get all user list from jira soap service without admin permission?

Part

This issue is incorporated by:

JRA-13297 SOAP Service Improvements - Especially with user management

JRA-12951 Consider adding a SOAP service to get all groups

Participants:	Anton Mazkovoi [Atlassian], Brock Janiczak, Frank Stiller, Ignacio Lopez, olivier gueydon and Yuen-Chi Lian [Atlassian]
Since last comment:	56 weeks, 2 days ago
Labels:

Description

« Hide

Currently there is no (easy) way for a remote client to discover a list of all user in a Jira installation. The best that you can do (if you are an admin user) is call getUsers(Group) where group is the jira-users group. It would be really handy if there were a service to get a list of all users in the system. With this information it would be possible for remote clients to provide user lookup facilities and mappings between user id's and real names.

However, I do understand that adding such a service opens the system up to abuse. It would be trivial to write a client that could harvest a list of valid email addresses from the system. Requiring the user to login before calling the service may help this a bit.

Here is the RPC service code:

UserServiceImpl.java

public RemoteUser[] getAllUsers()
    {
    	Collection usersCollection = UserUtils.getAllUsers();
    	RemoteUser[] users = new RemoteUser[usersCollection.size()];
    	
    	int i = 0;
    	for (Iterator iUsers = usersCollection.iterator(); iUsers.hasNext(); i++) {
    		users[i] = new RemoteUser((User) iUsers.next());
    	}
        return users;
    }

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] - 08/Jan/06 10:37 PM

Thank you for the suggestion. We would indeed need to make the access secure. Some JIRA installations have more than 10,000 users. We would also need a way to deal with large users sets.

Do you mind sharing this code with the rest of the community? If not, please post it on the JIRA Community Space:
http://confluence.atlassian.com/display/JIRACOM/Home

Thanks a lot for sharing teh code!

Anton

[ Permlink | « Hide ]

Brock Janiczak - 09/Jan/06 01:36 AM

Anton,
Instead of returning all users, perhaps a search api would be smarter?
something like findUsers(String partialFullName, String partialEmailAddress, int pageSize, int page) : User[]

Being able to filter on group would also be cool, but there is no way to list groups from the remote API

cheers,
Brock

[ Permlink | « Hide ]

olivier gueydon - 23/Mar/06 02:24 PM

For my needs, and it will deal with the security problem also, a method to get a list of all user names could be enough.
We could have a method to get a list of RemoteUser as the current getGroup function works now, and one which will only return a list of strings containing the usernames....
Then no more security issue I think (or at least much less)

Cheers

Olivier

[ Permlink | « Hide ]

Ignacio Lopez - 09/Nov/06 01:24 PM

Hi Guys! Any news on the status of this issue? I'm writing a Visual Studio 2005 plugin for JIRA and it's really a shame not having an easy way to list all the users assigned to a project.

[ Permlink | « Hide ]

Yuen-Chi Lian [Atlassian] - 13/Nov/06 06:23 AM

Hello Ignacio,

There will be a major tackle on most RPC/SOAP issues in future release. I can't really promise when it will be, but for the time being, as the source code is freely available, I will suggest you to modify it manually:

http://repository.atlassian.com/atlassian-jira-rpc-plugin/distributions/

Cheers,
Yuen-Chi

[ Permlink | « Hide ]

Frank Stiller - 21/Jun/07 02:58 AM

When will the major tackle come? Any schedule?

Give us some more possibilities on user management, otherwise we have to use direct SQL. I dont really want to extend any API on such basic functionality. Please think of improving the user management of your products a bit as they are not really complete (no renaming of users/groups, no nested groups, no real support for ldap, no getUsers/Groups methods ...)

thanks