[
https://issues.apache.org/jira/browse/JAMES-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3657.
---------------------------------
Resolution: Fixed
> 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: 4h 20m
> 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 [email protected]
> WHEN I create the user [email protected]
> THEN it fails
> ```
> ```
> GIVEN an alias [email protected]
> WHEN I create the user [email protected]
> THEN it fails
> ```
> ```
> GIVEN a group [email protected]
> WHEN I create the user [email protected]
> THEN it fails
> ```
> ```
> GIVEN a user [email protected]
> WHEN I create the alias [email protected]
> THEN it fails
> ```
> ```
> GIVEN an alias [email protected]
> WHEN I create the alias [email protected]
> THEN it fails
> ```
> ```
> GIVEN a group [email protected]
> WHEN I create the alias [email protected]
> THEN it fails
> ```
> ```
> GIVEN a user [email protected]
> WHEN I create the group [email protected]
> THEN it fails
> ```
> ```
> GIVEN an alias [email protected]
> WHEN I create the group [email protected]
> THEN it fails
> ```
> ```
> GIVEN a group [email protected]
> WHEN I create the group [email protected]
> THEN it fails
> ```
> h3. Reference to a previous proposal
> https://www.mail-archive.com/[email protected]/msg71116.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
