Management configuration system
Management configuration system
In the current state of the code, management screens can be configured through a configuration dialog, and such changes can be made persistent by saving them in the LDAP configuration node by users with enough rights (admin). Non-persistent changes are lost when leaving the management screen.
Problems, questions and ideas:
- It may be better if non-persistent changes were only lost at logout
- Users may want to have their own persistent changes? (Stored where? How to control such feature through ACLs?)
- Admins may want to offer pre-configured options to users (Stored where? Available how? ACLs? "Views"?)
- Configuration dialog should be easier to use and understand for non-expert users (Is there de-facto standards regarding column configuration out there?)
- What about filters, should we be able to add/remove some, or provide default values ? (I guess plugins should be able to add filters, maybe. Seems low prioriy anyway)
For selections screens, I think their changes should never be persistent. Not sure how filters and default columns should be computed.
Activity
changed milestone to %FusionDirectory 1.4
By Côme Chilliet on 2019-03-11T14:41:39 (imported from GitLab)
added PJ1802-0188 filters labels
- It may be better if non-persistent changes were only lost at logout
It was decided non-persistent changes would stay as they are (lost at leaving management page)
- Users may want to have their own persistent changes? (Stored where? How to control such feature through ACLs?)
It was decided that users should be able to make their changes persistent for them without any additional ACL.
- Admins may want to offer pre-configured options to users (Stored where? Available how? ACLs? "Views"?)
This has been postponed.
By Côme Chilliet on 2019-03-27T10:41:15 (imported from GitLab)
Users may want to have their own persistent changes? (Stored where? How to control such feature through ACLs?)
It should be stored in the configuration node, under a new attribute fdManagementUsersConfig which stores the same format as fdManagementConfig prefixed by the user dn.
By Côme Chilliet on 2019-03-27T13:53:20 (imported from GitLab)
mentioned in commit d784ad7e
By Côme Chilliet on 2019-04-16T13:06:44 (imported from GitLab)
added To Be Tested label
assigned to @jswaelens and unassigned @MCMic
By bmortier on 2019-04-25T05:32:30 (imported from GitLab)
Hello @MCMic
The persistent management configuration work well for admin and user.
But if I have a manager role with only read on few attributes (sn, givenName, uid) and a global write. I can display the attributs like cn and userPassword
By Jonathan Swaelens on 2019-05-27T09:23:09 (imported from GitLab)
I cannot reproduce this, if I give read rights only on sn and not givenName, the given name column is empty. Same thing for cn/userPassword.
@jswaelens Can you test again and explain how to reproduce this?
By Côme Chilliet on 2019-05-27T09:23:08 (imported from GitLab)
Hello @MCMic
I did the following steps on demo-dev to reproduce the issue.
- I edit my manager role to have the following rights
cn=manager,ou=aclroles createTimestamp 2019-05-26 20:55:20 modifyTimestamp 2019-05-27 08:27:05 cn manager description Donner tous les droits sur les utilisateurs de cette branche objectClass top objectClass gosaRole gosaAclTemplate 0:user/password;cmdrw,user/user;w#sn;r#givenName;r#uid;r-
I connect with the manager and add the column that will display the cn and userpassword
-
After validation I can see them
By Jonathan Swaelens on 2019-05-27T12:59:54 (imported from GitLab)
Ok sorry I read too fast and did not see the global write.
Indeed write implies read, it seems to be this way in FD since a long time, here is the culprit: https://gitlab.fusiondirectory.org/fusiondirectory/fd/blob/1.4-dev/include/class_userinfo.inc#L743
This is clearly intentional and I do not find it that surprising, since I do not see how the FD UI could handle it if a user is allowed to write a field without reading it.
By Côme Chilliet on 2019-05-27T13:24:54 (imported from GitLab)
Opened user-manual#55 (closed) on this subject
By Côme Chilliet on 2019-05-27T13:26:52 (imported from GitLab)
removed To Be Tested label
assigned to @MCMic and unassigned @jswaelens
By Jonathan Swaelens on 2019-05-27T08:20:47 (imported from GitLab)
