search

echocat / adam

Addon which enhances all user profiles of confluence. It also adds an advanced people directory. The whole addon is configurable by means of an XML, can be localized, supports Velocity templates and supports view and edit restrictions.
https://adam.echocat.org
GNU Lesser General Public License v3.0
11 stars 15 forks source link

Provide ability to sync fields back to LDAP directory #15

Open blaubaer opened 10 years ago

blaubaer commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

blaubaer commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

This feature would be really nice...