Benoit Tellier created JAMES-3655:
-------------------------------------
Summary: Quota extensions (mailbox plugins) do not take delegation
into account
Key: JAMES-3655
URL: https://issues.apache.org/jira/browse/JAMES-3655
Project: James Server
Issue Type: Improvement
Components: elasticsearch, mailbox
Affects Versions: 3.7.0
Reporter: Benoit Tellier
h3. Context
Me and my team are planning to work on Functional Mailboxes (mailboxes
belonging to a team) in our TMail product.
As such we want to support quotas for such functional mailboxes. In order to do
so, we conducted an audit of existing quota pugin in James.
Mailbox quota plugins includes:
- Quota search, allow filtering and sorting users by their quota usage,
allowing an admin to conduct actions.
- Over quota mailing emailing users regarding their quota use...
h3. Bug description
We found that the user definition in the two mailbox plugins is linked to the
user performing the action and not to the actual users the resources belongs to.
This can cause innacurate reports for users performing actions on mailboxes
shared to them.
I wrote the following test and it was failing- for the distributed version:
{code:java}
GIVEN two users (BOB CEDRIC) with 0/20 mails quota
AND CEDRIC delegates his mailbox to BOB
WHEN BOB adds 19 message to CEDRIC mailbox
THEN we expect CEDRIC to be reported with a 95% quota ration by quota search
{code}
h3. The proposed fix
We need to be able to, given a quota root, be able to find the user the
resource actually belong to.
The `QuotaRootResolver` sounds like the right place to enclose that knowledge:
{code:java}
public interface QuotaRootResolver extends QuotaRootDeserializer {
Username associatedUsername(QuotaRoot quotaRoot) throws MailboxException;
}
{code}
The above mentioned quota root extensions would then rely on it instead of the
user performing the action...
Bonus point: I strongly suspect this would be enough to make these extensions
usable in the context of shared mailboxes...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
