Enhancement #164
openSupport named paths
0%
Description
It would be useful to have names for paths, possibly with parameters, in order to avoid using DNs, and hide this complexity to the user. It would also help naming objects with the same characteristics but not the same place in the tree (like many organisationalUnit objects).
It would be nice to have absolute and relative paths. For example :- users -> ou=People,dc=milkypond,dc=org
- own_domains => ou=Domains,...
- spc_accounts -> ou=SpecialAccounts,...
So we could create a new user in 'users', a new domain in 'individual/<user>:own_domains', a new special account in 'entity/<entity>:spc_accounts', ...
Nevertheless, 'users' is also 'unit/people', which is somewhat redondant, event if using an object name is not enough to get a unique path (as it is equivalent to a deep search which can give several results). So, we need to find a common solution.
Updated by Marc Dequènes about 14 years ago
- root:unit/People
- individual/duck
- individual/duck:unit/Domains:domain/toto.net
- entity/hurdfr:unit/Domains:domain/hurdfr.org:system_account/hf-wiki
- individual/duck::domain/toto.net
- entity/hurdfr::domain/hurdfr.org:system_account/hf-wiki
(with maximum reduction depending on what is enforced-uniq at the database level, so 'domain/hurdfr.org' and probably 'system_account/hf-wiki' may already be uniq in this case)
Updated by Marc Dequènes about 14 years ago
With this method we can create new objects in a simpler way, without specifying the parent as an extra argument.
We also need to think about search results: what object name/path would be given back ?
Finding an object could be quite costly, but one-steps could allow calulating part of the final DN and simplify a bit. Handle customization, like proposed in #146, would probably cause problems.