[jira] [Commented] (JAMES-3657) WebAdmin: refactor entity validation upon creation

["Benoit Tellier (Jira)" <se...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/JAMES-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17423764#comment-17423764 ] 

Benoit Tellier commented on JAMES-3657:
---------------------------------------

Tung proposed to have this logic pushed to the repository level so that we can benefit from entity validation everywhere and not just in webadmin.

This is of course a refactoring proposal I do support, we are going to propose it as a follow up pull request.

h3. Definition of done


{code:java}
GIVEN a group toto@domain.tld
WHEN I try to create the user toto@domain.tld using the CLI
THEN it fails

GIVEN an aliastoto@domain.tld
WHEN I try to create the user toto@domain.tld using the CLI
THEN it fails
{code}


> WebAdmin: refactor entity validation upon creation
> --------------------------------------------------
>
>                 Key: JAMES-3657
>                 URL: https://issues.apache.org/jira/browse/JAMES-3657
>             Project: James Server
>          Issue Type: Bug
>          Components: webadmin
>    Affects Versions: 3.7.0
>            Reporter: Benoit Tellier
>            Priority: Major
>             Fix For: 3.7.0
>
>          Time Spent: 3h
>  Remaining Estimate: 0h
>
> h3. Why?
> James currently lacks some validation logic to ensure that when creating a new entity, it does not clash with existing entities having the same mail address in the system (users, aliases, groups, ...). To validate them, we could implement validation for each of them in each of them (O(n^2)) wich is both not extensible and not scalable.
> Instead, our proposed approach would be to just write n validators (O(n)), so one for each, and plug all of them into one aggregator, that the different routes managing concerned entities would check. Adding 1 entity would require only writing 1 validator then.
> h3. How?
> So, we could create a new interface called `UserEntityValidator` that would return a `ValidationResult` defined to hold if an entity exists or not and the nature of the entity:
> ```
> interface ValidationResult {
>    boolean asBool();
>    String entityName();
> }
> class SuccessValidationResult extends ValidationResult { ... }
> class FailureValidationResult extends ValidationResult { ... }
> interface UserEntityValidator {
>    ValidationResult exists(Username username);
> }
> ```
> Then we could have implementations of this validator for each entity in the system: users, aliases, groups:
> ```
> class AliasUserEntityValidator extends UserEntityValidator { ... } 
> class GroupUserEntityValidator extends UserEntityValidator { ... } 
> class AccountUserEntityValidator extends UserEntityValidator { ... }
> ```
> Finally we would multi-bind them all into an aggregate implementation `AggregateUserEntityValidator`:
> ```
> // This is the implementation we rely on, in every routes.
> class AggregateUserEntityValidator extends UserEntityValidator {
>    // All validators, for all entotoes, including extensions, managed by Guice.
>     private final Set<UserEntityValidator> validators;
>     
>     @Inject
>     AggregateUserEntityValidator(Set<UserEntityValidator> validators) {
>         this.validators = validators;
>     }
>     public ValidationResult exists(Username username) { ... }
> }
> ```
> h3. Definition of done
> Finally, we would need to answer the following cases regarding the tests:
> ```
> GIVEN a user marketing@linagora.com
> WHEN I create the user marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN an alias marketing@linagora.com
> WHEN I create the user marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN a group marketing@linagora.com
> WHEN I create the user marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN a user marketing@linagora.com
> WHEN I create the alias marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN an alias marketing@linagora.com
> WHEN I create the alias marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN a group marketing@linagora.com
> WHEN I create the alias marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN a user marketing@linagora.com
> WHEN I create the group marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN an alias marketing@linagora.com
> WHEN I create the group marketing@linagora.com
> THEN it fails
> ```
> ```
> GIVEN a group marketing@linagora.com
> WHEN I create the group marketing@linagora.com
> THEN it fails
> ```
> h3. Reference to a previous proposal
> https://www.mail-archive.com/server-dev@james.apache.org/msg71116.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org