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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.