On Saturday 27 November 2010 12:30:24 Andreas Dick wrote:
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.
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.
- 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?
- 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 :)
- 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.
- 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/aba52c80