On Friday 26 November 2010 17:14:46 Andreas Dick wrote:
WOW, the LDAP discussion is going on. great! I am really not a LDAP guru, but I think others here are. Well, I will continue this discussion to find out how a good implementation could become. I will then try to implement it somehow, at least for me, but others could be interested as well....
I think if we can get the design ironed out, it will be very usefull :)
I try to conclude the feedback and my opinion:
- The "name" topic is somhow personal and must be configurable. The "name"
contains firstname, surname, middlename title, and what ever, but in my opinion it must not be editable its own, only the parts of it.
Ok, I take it this is in the interface? Don't want to repeat myself, but the address-book functionality of eGroupware is quite good. Here, it is done similarly to how you describe. There is a "name" field, that consists of different fields. When trying to edit this field, a pop-up appears where the different "sub-fields" are listed. These can then be edited.
I think, from the interface point of view, that is what you are talking about?
Another question is, what is used as identifier, the DN on the LDAP. I think in RC the composed "name" is used, and I can live with that. For the DN I have seen the CN (which corresponds to the "name" field) or even the email address. This can allready be configured with now (LDAP_rdn).
Yes, except I do tend to prefer a UUID as the DN.
A single person can have multiple email addresses, eg. that is not useful. And I have seen situations where different people had the same names. (Just check the amount of email-addresses in companies with numbers...)
- what field is necessarry for a valid addressbook entry is depending on
the situation as well, it must be configurable. In RC 0.4.2, the "email" and "name" fields are mandatorry (in program/steps/addressbook/save.inc and program/js/app.js), but if I add e.g. an entry from my cell phone with just a surname and a phone number, I will as well be able to change the phone number with RC without setting a valid name/email... clear what I mean?
I think we should have what the LDAP schema expects as mandatory also mandatory in the interface. I also have people in my addressbook without email, but do have a phone number. Or, sometimes, someone temporarily only has his/her name in the addressbook (migrating to different country, but new address/phone/... doesn't exist yet)
I would try to keep the "minimum" entry to whatever we decide as the DN + Name-fields
- another topic is how to parse an email address in the "addcontact"
feature. In my opinion it is too simple today. The best would be to let it configured as well.
I personally would prefer if it would open a pop-up (or whatever) that would allow me to type the name for this person.
- how to implement address groups? My first try will be to use simple
subdirectorries for the groups. It fits all my needs and I will try to implement add/del/change groups in RC. This could look like that: my base_dn: ou=abook,dc=server example of an ungrouped address : cn=Firstname Surname,ou=abook,dc=server group exsample: o=My Groupe,ou=abook,dc=server example of an grouped address : cn=Firstname Surname,o=My Groupe,ou=abook,dc=server
Patrik pointed that ou would fit better for the group: ou=My Groupe,ou=abook,dc=server I think this should be configured as well.
I agree, apart from where the "ungrouped" address comes in. I would do it as follows:
ungrouped defaults to Global: dn=<uuid>,o=Global,o=Groups,ou=abook,dc=example,dc=org
something in the addressbook belonging to group/project "alpha": dn=<uuid>,o=alpha,ou=abook,dc=example,dc=org
something in my personal addressbook: dn=<uuid>,o=joost,o=Personal,ou=abook,dc=example,dc=org
This would also make it easier to configure ACL (security) for the LDAP-tree. The specifics for that is best left to the LDAP-experts at a later stage, but this does need to be taken into account at the design stage.
- the last issue is the configuration topic. The question is, how to
configure that lot of information without redundancy? I will let you know if I have a proposition.
For my example above, I'm thinking along the lines off: "addressbook_base_dn" = "ou=abook,dc=example,dc=org"
"addressbook_groups" = "o=Groups" "addressbook_private" = "o=Personal"
And in the code, add the "base_dn" bit to the other configuration fields.
And I would also think it's a good idea to be able to specify which field in LDAP corresponds to which field relevant for RoundCube.
-- Joost _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80