LdapShadows: Issueshttps://projects.duckcorp.org/https://projects.duckcorp.org/favicon.ico?16699090422010-10-24T09:27:14ZDuckCorp Projects
Redmine Enhancement #164 (New): Support named pathshttps://projects.duckcorp.org/issues/1642010-10-24T09:27:14ZMarc Dequènesduck@duckcorp.org
<p>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).</p>
It would be nice to have absolute and relative paths. For example :
<ul>
<li>users -> ou=People,dc=milkypond,dc=org</li>
<li>own_domains => ou=Domains,...</li>
<li>spc_accounts -> ou=SpecialAccounts,...<br />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', ...</li>
</ul>
<p>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.</p> Bug #150 (New): find a way to name non-unique itemshttps://projects.duckcorp.org/issues/1502010-09-08T20:03:16ZMarc Dequènesduck@duckcorp.org
<p>(examples with the MilkyPond world)</p>
<p>If individuals are unique accross the whole database, it could be nice to limit this unicity to unit/People and allow user's address books. So, individual/duck may have several address books under its entry, and possibly with duplicated contacts. We will end-up with individual/toto being in several places, and with to way to select the right one to manipulate. We need to find a way to specify these kind of entries in a simple way.</p>
Something like this could do:
<ul>
<li>unit/People:individual/toto</li>
<li>individual/duck:addressbook/mycontacts1:individual/toto</li>
<li>individual/duck:addressbook/mycontacts2:individual/toto</li>
</ul>
<p>It is a bit lenghty, but ensure proper unicity in all cases. it would be necessary to discover the shortest <em>handle-path</em> for search results. The big problem with this solution is the <em>handle-path</em> is not persistent during time : unit/People:individual/toto will still be valid, but individual/toto would be the shortest path if the two others disappear (and the reversed situation would be even worse).</p> Enhancement #146 (New): allow providing method to compute a better item handlehttps://projects.duckcorp.org/issues/1462010-09-06T20:38:00ZMarc Dequènesduck@duckcorp.orgEnhancement #145 (New): allow providing method to compute object namehttps://projects.duckcorp.org/issues/1452010-09-06T12:07:10ZMarc Dequènesduck@duckcorp.org
<p>It would be more flexible than a single attribute name, or even a list, and we can still provide helpers for common cases.</p> Enhancement #143 (In Progress): create administration shadow for OpenLDAP 'cn=config' database/worldhttps://projects.duckcorp.org/issues/1432010-09-06T08:25:51ZMarc Dequènesduck@duckcorp.org
<p>It would help much handle the new slapd.d configuration system.</p> Enhancement #127 (New): Templated creationhttps://projects.duckcorp.org/issues/1272010-08-13T10:42:26ZMarc Dequènesduck@duckcorp.org
It would be nice to specify a template at object creation time in order to:
<ul>
<li>apply default values</li>
<li>have hooks behave according to it if necessary</li>
</ul> Enhancement #24 (New): Support X-ORDERED attributetypeshttps://projects.duckcorp.org/issues/242010-04-05T17:06:24ZMarc Dequènesduck@duckcorp.org