[
https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Gazda updated MAILBOX-167:
---------------------------------
Assignee: Jochen Gazda (was: Norman Maurer)
Assigning to me.
> Make the namespace handling consistent and predictable
> ------------------------------------------------------
>
> Key: MAILBOX-167
> URL: https://issues.apache.org/jira/browse/MAILBOX-167
> Project: James Mailbox
> Issue Type: Bug
> Reporter: Jochen Gazda
> Assignee: Jochen Gazda
>
> (1) in StoreMessageManager.isGroupFolder(MailboxSession), if the
> present folder is the current user's INBOX, mailbox.getNamespace() and
> session.getPersonalSpace() should return the same value, which they do
> not. This makes some ACL commands to fail.
> I could achieve the desired behavior when I changed this part of
> SimpleMailboxSession constructor from
> if (otherUsersSpace == null && (sharedSpaces == null ||
> sharedSpaces.isEmpty())) {
> this.personalSpace = "";
> } else {
> this.personalSpace = MailboxConstants.USER_NAMESPACE;
> }
> to
> this.personalSpace = MailboxConstants.USER_NAMESPACE;
> Can this cause any unwanted consequences?
> (2) in AbstractMailboxProcessor.buildFullPath(ImapSession, String),
> MailboxConstants.USER_NAMESPACE is used on two places where IMO
> mailboxSession.getPersonalSpace() would be a better choice just for
> the case that -- for whatever reason -- the session gets configured
> differently. Is it a good idea?
> (3) I find the rewriting of "" and null namespace values to
> MailboxConstants.USER_NAMESPACE in MailboxPath(String, String, String)
> constructor problematic. Callers should be fully responsible for the
> namespace value.
> "" should be allowed as a legal namespace prefix, e.g. for a shared namespace.
> As for null, is there any good reason for the rewriting?
> I see that changing the rewriting of "" and/or null namespace in
> MailboxPath would enforce an extensive refactoring.
> (4) MailboxPath has three fields: namespace, user and name. We should
> make them final and their setters should be removed to avoid
> unauthorised or unexpected changes. As far as I can see there are only
> a few easily refactorable locations where the setters are invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
