Delegation storage API: memory implementation

[Arsnael]

Based on the work done regarding delegation in apache james, you need to add an API to manage account delegations of a user.

Thus in AccountDelegation, you could add those extra methods:

• void addDelegatedAccount(username: Username, accountId: accountId) => PUT /users/{username}/accounts/{accountId}
• void removeDelegatedAccount(username: Username, accountId: accountId) => DEL'ETE /users/{username}/accounts/{accountId}

DoD: Write a memory implementation of it and its contract to show it works accordingly

[chibenwa]

Few remarks:

• 1. As an administrator, I do NOT want to work with an accountId, I want to work with a username.

Think:

• allow vstef@lng.com to access azap@lng.com
• rather than allow vstef@lng.com to access 54684348-483835488-553853548568

Which one would you prefer working with in WebAdmin?

• 2. You do not expose methods for reading data as part of this API ?
• 3. Why are we mixing rest calls within a Java API definition
• 4. Reactify this!

In https://app.zenhub.com/workspaces/team-james-5873652b2a0b13cc0b8bbe63/issues/linagora/james-project-private/78#issuecomment-784719859 I did work on a sum up of the overall architecture, this API would look like:

trait DelegationStore {
  def listDelegatedUsers(username: Username): SFlux[Username]
  def addDelegatedUser(accessor: Username, accessee: Username): SMono[Unit]
  def removeDelegatedUser(accessor: Username, accessee: Username): SMono[Unit]
  def isDelegated(accessor: Username, accessee: Username): SMono[Boolean]
}

(Can be implemented in Java)

Question: where (which maven project) is this class located?