User type organization unit changes and attribute uniqueness scope

[ThaminduDilshan]

Problem Summary

Two undefined behaviours around user types, split out of the user type flexibility discussion so that thread can stay on the attribute configuration question. Both need a decision regardless of which direction that one takes.

Issues

1. Changing a user type's organization unit has no defined behaviour.

   • A user type belongs to one OU, and users of that type must be in that OU or below it. Update lets the OU change with nothing but an authorization check on both sides.
   • Moving it deeper leaves existing users outside the new subtree, and they fail validation on their next update.
   • Moving it higher silently widens who may hold the type.
   • We never decided which of these should be allowed, so today both are.

2. A unique attribute is only enforced in one direction.

   • Uniqueness is checked only for attributes the type being created marks unique, but the lookup itself spans every user in the organization with no type, category or OU filter.
   • So if Customer marks email unique and Staff does not, a Customer cannot reuse a Staff email, while a Staff user can freely reuse a Customer one.
   • Uniqueness being organization wide also means organization units are not an isolation boundary for usernames or emails.

Questions for Community Input

1. Should changing a user type's organization unit be blocked entirely, allowed only when no existing user falls outside the new subtree, or allowed only upward?
2. Should user type names be unique per organization unit rather than per organization?
3. On a schema change, should referencing configurations be revalidated immediately, or corrected on next save as today?
4. Should attribute uniqueness be scoped per user type, per organization unit, or per organization?
5. Should a type be able to declare an attribute unique when another type does not, or should uniqueness be a property of the attribute rather than of each type's schema?