...

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