Re: Webadmin: object type attributes definition

On Friday, September 28, 2012 03:10:03 PM Aleksander Machniak wrote:
> I'm working on types management and see that attributes definition could
> be clearer. I propose some simplifications.
> 
> 1. I think all these three arrays (auto_form_fields, form_fields,
> fields) should be merged into one 'attributes' hash.
> 
> 'attributes' => array(
>   'auto_form_fields' => array (
>      'cn' => array (
>         'data' => array (
>             0 => 'givenname',
>             1 => 'sn',
>           ),
>         ),
> 
> would be changed to
> 
> 'attributes' => array(
>   'cn' => array(
>     'auto' => true,
>   ),
> 
> One issue to resolve will be the way to define which of auto-fields can
> be editable. Before, it was done by adding attribute to form_fields and
> auto_form_fields. Now, it could be just 'readonly' attribute.
> 

IIRC, auto_form_fields could always be made editable by including their id in 
form_fields with 'optional' => true.

Also, let's note that whether or not a form field is readonly is not only 
influenced by whether the form field value is automatically generated, but 
also ACL restrictions.

> 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?

> 4. In mean time I got a request to add a possibility to mark some of
> auto-fields as hidden, so they would become hidden in the form. This can
> be useful in signup form. I propose to just add 'hidden' flag.
> 

This request isn't in Bugzilla, so it doesn't exist.

> 5. There's 'maxcount' value limiting list elements size. It's used only
> with 'alias' attribute. Should it be still user-configurable or this
> should be also moved to the API?

For types management, this should still be configurable for the user. It 
should be used in the client UI, or submitting a list with length 5 with the 
API slicing off items or returning an error is cumbersome behaviour at best.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEABECAAYFAlBlo+EACgkQKN6f2pNCvwiAqACgvfxH5rBWJF4MviQgTwIcWjtX
76oAn0YUiKRLyMz8lL15sUo726T+azrb
=wr11
-----END PGP SIGNATURE-----