On Fri, 26 Nov 2010 18:56:43 +0100, "J. Roeleveld" <[email protected]> wrote: >> 1) 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... >> 2) 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. > >> 3) 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! > >> 4) 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. > >> 5) 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/8f4f07cd
