Provide ability to sync fields back to LDAP directory

[blaubaer]

Give a user and admin the chance to edit fields in confluence (example mobile phone) and sync it back to the LDAP directory. In this case the administrators and users have a easy user interface to edit their data.

[feisley]

A couple thoughts: First this assumes that the directory is placed in read/write mode, otherwise it wont allow updates to push to LDAP.

If it is enabled for read/write, will it be possible to restrict who can edit a specific field? For example allow a user to edit their phone number, but do not let them edit their email.

[blaubaer]

I think keep it stupid simple. ;) If the access rights allow to edit a field for the current user who edit a field and the push back function for this field is enabled, then it will be pushed back. An extra access layer only for push back function will be confusing for every one. Or?

[feisley]

So we already can specify if the user is allowed to modify vs an admin. So the only change would be an attribute to the field that defines if it is allowed to push back? Or would we simply assume any field change on a read/write directory would get pushed?

[blaubaer]

Did you mean: If we enable the push back function for Adam global, the directory is read/write and a user can edit a field this field also will be pushed back on edit this field?

[feisley]

I am asking if the push back function is enabled globally or on a per field basis.

[blaubaer]

Mhh... that's the question. Will it be to much configuration if we make it editable per field - I think it is enough to make this global and follow the mentioned assumptions.

[feisley]

I agree, worse case you simply specify on the field that no one is allowed to edit it that should cover restricting a single field. I see little reason to allow a field to be edited but leave it out of sync with the directory.

[blaubaer]

Ok this feature will be also a little hack. I love Atlassian that they provide a so good API to interact with the directories. If you see my code you know what I mean. But no problems; no challenges. ;-)

[feisley]

Thought of a potential snag with this: With the current design the Velocity template is applied and then the result is presented in the view and editor. Given that the template is one way, if a user makes an edit to a field with a template, how would the system be able to translate that back to the raw field?

[blaubaer]

Yeah. This is no simple thing. I think the way that the velocity tempates are applied to the data from the active directory have to be removed. The velocity templates have to be only applied to the output. This makes it also easier for #7. There is a sample problem. How to deal with it.

The solution could be the views, that combine multiple elements for the output. Same like #29 where we move the order and <group> to the views.

The result will be that in the edit mode of the elements you never edit a view. You edit the plain elements and this could be easy synchronized with the LDAP directory because there are in the same format.

But also here: Structure change will be required. :-/

[pcernocky]

This feature would be really nice...