What I am saying is that there is a soap request to change user preferences, not for changing user properties.
the request to change the user property to enable/disable the Calendar feature is available on the admin console side, not on the client side.
And yes those fields are stored at the same place, but the LDAP modification is done on server side after the reception of the soap request.
So I suppose that zimbra when it manage the soap request, check if the value the soap request ask to modify is in the list of the value a user can change.
* user properties are hold within the user objects in LDAP
* js client code holds them and allows arbitrary changes and adding new ones locally
* it writes them back to LDAP via an SOAP call
* that SOAP call will protect specific properties that may not be changed by the user.
By the way: do those additional properties easily survive an upgrade ?
(you know, LDAP schemata tend to be incompatible between different
ZCS versions and the update process handles the conversion).
Zimlets user properties is one field, with multi-values. Each value is stored in this field with the format :
So yes, it can easily survive an upgrade.
Seems our previous way of storing that information in an separate
mysql table was quite hackish. In future, we'll have to find a solution
to handle user movals anyways, so perhaps we can cooperate and
develop a more generic zimlet using your approach that also satisfies
I corrected a bit my example and updated the attachment.
You can just use it, modify the title and the put the HTML you want in the body of the dialog box.
Is there anything else to do?