[Kolab-devel] enlargement of kolab ldap schema for asp service

[Alain Spineux]

On 7/24/07, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Hi Thomas, hi Bernhard,
>
> Bernhard Reiter <bernhard at intevation.de> writes:
>
> > Hi Thomas,
> >
> > On Monday 23 July 2007 19:04, Thomas Börnert wrote:
> >> i plan to use kolab as a asp solution and need some additional
> >> ldap attributes.
> >>
> >> i need the new attributes only for the web administration frontend.
> >>
> >> i'd a offline discusstion with gunnar wrobel and he recommends to
> >> use a generic ldap attibute as "kolabPrefs" or "kolabWebadminPrefs".
> >> in this case there this is a generic solution for all other improvments,
> >> and it is not necessary to extend the ldap schema for each additional
> >> function.
> >
>
> The original discussion has been in German and I'll just translate my
> original response into English.
>
> Let me summarize the original problem first:
>
> The ideas proposed by Thomas were mainly concerned with usability
> features for the kolab-webadmin. He desired to store a number of
> preferences within the LDAP tree.
>
> > can you summarize the whole proposal of adding these attributes
> > again?
>
> Basically your proposed features are centered around the usability of
> the kolab-webadmin. Most features you suggested seem to be useful
> indeed. What do envision as difficult though are any modifications to
> the Kolab-Server-LDAP-Schema. I'm no LDAP-Expert but as far as I know
> these Schemata should be as stable as possible. Once we start
> introducing the preferences of external tools into the schema we will
> have to modify it rather frequently.

This is just adding fields.
You can have a full range of fields named :

kolabprefix-compagnyname-fieldname

I compagny Intervation request to add the field Quotamax, you have just to
create field (if prefix is Kolabplugin ): KolabpluginIntervationQuotamax

>
> Something like the "uidPrefix" you proposed would be highly specific
> to the kolab-webadmin and most users might not use it at all. I regard
> adding a new attribute into the schema for that as too complex.

Kolab team dont need to manage it, just add it

>
> I'd rather propose adding a generic attribute such as "kolabPrefs" (or
> more specifically "kolabWebadminPrefs") and store generic
> variable/value pairs within this attribute. So you would store
> something like "uidPrefix=pop-22003" as a base64 encoded string within
> the LDAP-Tree. This way storing parameters for a specific external
> tool would be rather flexible and would not necessitate modifications
> to the LDAP schema.

base64 will make thing difficult to debug, or maybe one

kolabWebadminPrefs for text field
and
kolabWebadminPrefs64 for base64 encoded one

>
>
> This was my original proposal and I stil believe it make sense to
> introduce something like that into the k=kolab object. I'm actually
> more in favor of a general "kolabPrefs" attribute since it could be
> used by just any external tool we want to modify so that it works
> together with the Kolab-Server-LDAP database.

This must be in user too, and one k=kolab object per domain.
Also one tree per domain where developers could store their own object

Regards

>
> Cheers,
>
> Gunnar
>
> --
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>
>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>
> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


-- 
--
Alain Spineux
aspineux gmail com
May the sources be with you