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

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

Benoit Tellier created JAMES-3657:
-------------------------------------

             Summary: 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
             Fix For: 3.7.0


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