Re: Webadmin: object type attributes definition
Jeroen van Meeuwen <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kolab,gmane.comp.kde.kolab.devel |
|---|---|
| Message-ID | <[email protected]> |
On Friday, September 28, 2012 03:25:43 PM Aleksander Machniak wrote: > On 09/28/2012 03:19 PM, Jeroen van Meeuwen wrote: > >> 2. As you see above I removed also 'data' definition. The list of > >> attributes used for auto-generation of attribute values is hardcoded in > >> API code. It means we cannot change this. > > > > How/where is the list of attributes used for auto-generation hardcoded? > > All generate_* methods in kolab_api_service_form_value class. E.g. > generate_cn(). While it checks auto_form_fields, the method used later > is hardcoded: > > $cn = trim($postdata['givenname'] . " " . $postdata['sn']); Right - I see what you mean. I suppose the same goes for displayName and uid. The reason they are hard-coded is not because I want it that way, but because it is rather difficult to come up with a sensible, configurable policy for them, and implement it, without types management controlling what attribute values are submitted to the form_value.generate_* functions in the first place. If we take the existing recipient policy as an example - it is configured via /etc/kolab/kolab.conf settings. We can't write to this file (nor should we aim to be able to write to it). The recipient policy is somewhat special in that it requires the need for the policy to be in the configuration file, as the kolabd service uses the settings and implements the policy as well. For cn, uid, displayname, homedirectory, and other such attributes however (especially those that are to contain a singular value), given that no kolab daemon relates to their value generation or implementation, I suppose we could make the API do magic, perhaps with the backing of the types management and so forth. Long story short; the fact they are hard-coded now should not impact what we plan to do with them. Perhaps it is as simple as adding a 'policy' key right where also 'data' is. Kind regards, Jeroen van Meeuwen -- Systems Architect Kolab Systems AG Zürich, Switzerland e: [email protected] t: +41 43 501 66 91 m: +44 74 2516 3817 w: http://kolabsys.com pgp: 0x9342BF08 _______________________________________________ Kolab-devel mailing list [email protected] https://www.intevation.de/mailman/listinfo/kolab-devel
signature.asc
(application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEABECAAYFAlBlpu0ACgkQKN6f2pNCvwhiZACgqta2QhKIBSHtTkz9O3XVrFeE SjIAoMxzwHKVgXO2gjx6Xb2GZwdhtv03 =1u0O -----END PGP SIGNATURE-----