On Fri, 26 Nov 2010 18:56:43 +0100, "J. Roeleveld" joost@antarean.org wrote:
- 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?
Yes. but for me, it doesnt matter how the interface looks like, but the meaning of the fields must be fixed first.
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...)
I know what you mean, but in the LDAP world I have not seen yet a DN like that... can otherwhat mean the LDAP gurus about that? how would this UUID be build? will other clients be able to handle that? I remember that I have seen CN=?+MAIL=?,DC=? as DN... but I have problems with the Email because I have lot addresses without email...
- 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
Yes.
- 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.
Yes, another good idea!
- 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.
this is your example, and we should have RC configurable for this as well.
- 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.
Yes. I can also imagine a group-filter like we have allready for entries.
Andreas
-- Joost _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/f0a00374
List info: http://lists.roundcube.net/dev/ BT/aba52c80