On Saturday 27 November 2010 12:30:24 Andreas Dick wrote: > 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.
Ofcourse, but described like this, I can follow it :) > >> 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... I actually have this for one of the addresses in my personal addressbook: uid=0d5233afef3ab65651b85312e2e1c77c,cn=joost,ou=personal,ou=contacts,o=egw,dc=antarean,dc=org And this in the global addressbook: uid=00eb9688ee101b804941344f962e631b,cn=default,ou=shared,ou=contacts,o=egw,dc=antarean,dc=org The UUIDs are generated by the groupware application I am currently using. Reason for that is, it allows me to use GROUPDAV to access the addresses from my desktop application. > >> 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. Ok, if noone has any other ideas here, I would then suggest we decide to keep this as minimum entry? > >> 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! Plenty more ideas where that one came from, just don't have the time to actually try to implement them all :) > >> 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. True, but also take into account that this is how most existing tools operate currently. I based this design on what I found online and this is very easy to configure into other existing products. > >> 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. Yes, configurable filters are very useful, especially for people who are not comfortable with writing the ACL-lists to restrict it there. Just had another thought, have the authentication with LDAP based on the username/password for the user logged in. But also allow anonymous and a global user-account to be configured where necessary. -- Joost _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/8f4f07cd
