...

Basically if the fifer API can do all this, and I rewrite the Grouper-Atlassian connector to use the fifer client (if we have one), then that connector could be used against any fifer complaint compliant group store.

Operations

Add member

...

• Input takes a netId and a group name
• Returns if the user is a member (note, Grouper returns if a member, if it is immediate or effective, though Atlassian does not care)

Create group

• Input takes the folder (namespace), and group name, and description, and the edit type (INSERT / UPDATE / INSERT_OR_UPDATE)
• Return doesn't matter

...

• This is used for atlassian to know the complete list of groups.  The implementation of the connector knows that something is an atlassian group since it is in the atlassian folder (configured somewhere in the folder structure).  This could also be implemented with group "types" or labels on the group...
• Input takes a folder, in grouper's case also pass in if you want groups immediately in the folder, or if it can also be in any subfolder, in this case we need folder or subfolder
• The interface needs the group name returned, though grouper returns the group details (name, description, etc)
• Note, this is the same web service operation as "Find group by name"

Update group

• There is a "store" method in the interface for groups, which I would assume would edit the attributes, though the only attribute Atlassian uses is group name, and there is no way to edit that, so in this case I think the operation is a no-op, and only in the UserProvider interface for other reasons than for groups...

Lookup subject

• Input takes a set of sources to look in, and a subject ID or identifier (depending on config)
• Return the subject
• This is for the "handles()" method which is supposed to return true if the adapter handles this subject, i.e. if the subject exists

Get members with attributes

• This is for the profile provider (to manage users/name/emails outside of Atlassian)
• Note, this could be implemented with a combination of other operations
• Input: group name from config file, subject sources to filter on, and attributes to return
• Return the members, with id, name, and email

Lookup subject with attributes

• This is for the profile provider (to manage users/name/emails outside of Atlassian)
• Input: username, optional group name from config file (if constraining Atlassian users to a certain group), subject sources to filter on, and attributes to return
• Return the subject, with id, name, and email

Notes

• It would be nice if the client could do some caching, since Atlassian does not do caching, and calls operations a LOT.  Right now the connector does the caching since the Grouper client does not yet cache...