hello Roundcube Devs WOW, Rouncube is realy cool! Yes, its just what I need for my home server.
What I miss is a more felxible LDAP Addressbook. I allready started to hack RC for my needs, but I am not sure if my changes are wellcome since I have seen that it is planed to rewrite the addressbook in further releases... isnt it?
And my changes are still verry personal and not that good configurable like it sould be at a commit. And another problem is, that I have setup my LDAP server my own, thus I am not sure about "standars" on that side.
Features I implemented allredy:
- more fields like address, phone nubers, notes, and the flexibility to
add more in the config file.
- the "name" field is redundant, it is just "surname lastname", thus it
must not be shown and editable.
- it must be able to let the "email" field empty, because a lot of my
addresses just have an address or phone number (used on the cell phone) -> the only field that is necessarry for the LDAP DN is the surname.
- adding new fields out of the E-Mail tool improved: email address is
now read as: "firstname surname email@bla" or "surname, firstname email@bla" or "surname email@bla" or "firstname.surname@email.bla" or "surname@email.bla" even mor sensefull syntaxes can be added.
- if the "name" allready exists, the entry can not be added, but the
email can be added if empty (for my cellphone adresses i like to compleet with email in RC)
Features I have planed to implement soon:
- group management: read groups out of the LDAP, create and remove
groups. (I still looking for a "standard- like" LDAP implementation of address groups, I tried allready to use the "o:" attribute, but I think it is better to use seperate LDAP subdirectories for each group)
The question is now: is it welcome if I prepare this to commit once? or is it even allready done in the latest SVN? (I use the stable 4.2 as base)
thanks for feedback Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 25.11.2010 17:17, Andreas Dick wrote:
Features I have planed to implement soon:
- group management: read groups out of the LDAP, create and remove
groups. (I still looking for a "standard- like" LDAP implementation of address groups, I tried allready to use the "o:" attribute, but I think it is better to use seperate LDAP subdirectories for each group)
This would be nice contribution. Roundcube devs are not LDAP gurus.
The question is now: is it welcome if I prepare this to commit once? or is it even allready done in the latest SVN? (I use the stable 4.2 as base)
Thomas is already working on this. Check devel-addressbook branch. We definitely will need a help with LDAP related part.
https://svn.roundcube.net/branches/devel-addressbook
Am Donnerstag 25 November 2010, um 17.31:21 schrieb A.L.E.C:
On 25.11.2010 17:17, Andreas Dick wrote:
Features I have planed to implement soon:
- group management: read groups out of the LDAP, create and remove
groups. (I still looking for a "standard- like" LDAP implementation of address groups, I tried allready to use the "o:" attribute, but I think it is better to use seperate LDAP subdirectories for each group)
This would be nice contribution. Roundcube devs are not LDAP gurus.
tja, I am not really a LDAP guru, but I digged the last monthes a lot of LDAP homepages because I got the impression that an LDAP server is the only independend solution for my addresses which can be used with allmost every client around (as the IMAP for email is). I wrote as well perl scripts for syncing my cell phone (vcard) with the LDAP server, as well as my addresses stored in an excel sheet (after exporting to csv). At the end I will have just one source, and RC is allready the best editor i have for now.
The question is now: is it welcome if I prepare this to commit once? or is it even allready done in the latest SVN? (I use the stable 4.2 as base)
Thomas is already working on this. Check devel-addressbook branch. We definitely will need a help with LDAP related part.
I checked it out, the most of my stuff is allready done...! unless e.g. the "addcontact out of the email" stuff -> I will apply a patch to trac. and rcube_ldap.php did not change a lot since 0.4.2... I will try make my actual code stable and conform with the svn code, and try to implement the group stuff. But I have first to find out, if my LDAP stuff is as general as I think...
Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
Hi Andreas,
On 2010-11-25 16:17 UTC Andreas Dick wrote:
Features I implemented allredy:
- more fields like address, phone nubers, notes, and the flexibility to
add more in the config file.
Sounds great.
- the "name" field is redundant, it is just "surname lastname", thus it
must not be shown and editable.
Please think of other languages and scripts, where it's not that simple. A large amount of people write their family names first, and then their given name(s), not separated by commas or spaces (for example Chinese - see http://en.wikipedia.org/wiki/Chinese_names). So it's not that simple. Maybe output of the name should be determined by an additional field, that's linked to a format string*, or something. Or there must be a separate 'displayName', but that requires entering the name(s) twice. Or there should just be one 'Name' field, which can be set in any way one wants, but where it's up to the person reading it, to figure out what's the family name, and what's the given name - maybe that's even the most sane thing to do ;)
*) for example like this: A field 'Name format' could have values such as
- 'Western (Given Middle Family)' => printf('%s %s %s', givenName, middleNames, familyName)
- 'Western (Family, Given Middle)' => printf('%s, %s %s', familyName, givenName, middleNames)
- 'Western (Family, Given)' (just omitting middle name(s)) => printf('%s, %s', familyName, givenName)
- 'CJK' => printf('%s%s', familyName, givenName)
- ... and probably many more ...
The input fields for givenName, middleNames and familyName should probably be arranged depending on the chosen Name format, so the person can write the name in the way she is used to write names. A default 'Name format' must be configurable (after all, there are lots of people who don't have names of people from around the world in their address books).
Features I have planed to implement soon:
- group management: read groups out of the LDAP, create and remove
groups. (I still looking for a "standard- like" LDAP implementation of address groups, I tried allready to use the "o:" attribute, but I think it is better to use seperate LDAP subdirectories for each group)
I don't know how this is usually done, but I don't think 'o' (Organization) is suitable. Maybe 'ou' (Organizational Unit)? Or maybe use 'groupOfNames' with many 'member' values?
It's probably best to stick to an established Schema (inetOrgPerson etc.), so for example Mozilla Thunderbird finds the LDAP directory useful as well (although that would be limiting, since Mozilla's LDAP support is a bit of a joke).
Patrick.
On Thursday 25 November 2010 17:17:37 Andreas Dick wrote:
hello Roundcube Devs WOW, Rouncube is realy cool! Yes, its just what I need for my home server.
What I miss is a more felxible LDAP Addressbook. I allready started to hack RC for my needs, but I am not sure if my changes are wellcome since I have seen that it is planed to rewrite the addressbook in further releases... isnt it?
And my changes are still verry personal and not that good configurable like it sould be at a commit. And another problem is, that I have setup my LDAP server my own, thus I am not sure about "standars" on that side.
There aren't really standards as such, everyone does it in a sort-off different way. Any implementation should be flexible enough to work with this.
Features I implemented allredy:
- more fields like address, phone nubers, notes, and the flexibility to
add more in the config file.
- the "name" field is redundant, it is just "surname lastname", thus it
must not be shown and editable.
I would use the name-field anyway, as this can then include any additional items. Please take into account that in certain countries (Germany, for instance) someone with a title wants to have that acknowledged.
- it must be able to let the "email" field empty, because a lot of my
addresses just have an address or phone number (used on the cell phone) -> the only field that is necessarry for the LDAP DN is the surname.
I would use a different DN then the surname. How will you handle a situation where your brother has a different address? (But will have the same surname)
I think some kind of unique identifier would be usefull here. Maybe have a look at how other projects, like egroupware, work?
- adding new fields out of the E-Mail tool improved: email address is
now read as: "firstname surname email@bla" or "surname, firstname email@bla" or "surname email@bla" or "firstname.surname@email.bla" or "surname@email.bla" even mor sensefull syntaxes can be added.
- if the "name" allready exists, the entry can not be added, but the
email can be added if empty (for my cellphone adresses i like to compleet with email in RC)
Are you putting the "name" in the "email"-field already? I wouldn't do this, to be honest as it makes matching difficult/impossible for mail clients to identify where the email came from.
Example of what I'm talking about: I put pictures with some of my contacts in LDAP My desktop mail-client (KMail) recognises the FROM-email address and puts the picture of the sender in the header If I put the full name as well into the email-address, then this feature doesn't work.
Features I have planed to implement soon:
- group management: read groups out of the LDAP, create and remove
groups. (I still looking for a "standard- like" LDAP implementation of address groups, I tried allready to use the "o:" attribute, but I think it is better to use seperate LDAP subdirectories for each group)
For groups, I would create a seperate "ldap" tree per group and use that.
The question is now: is it welcome if I prepare this to commit once? or is it even allready done in the latest SVN? (I use the stable 4.2 as base)
I'm not good with PHP, but I do know my way around LDAP and how to integrate different products to use the same LDAP-installation for my user accounts and addressbooks (global, personal, business-related,...)
I wouldn't mind helping with this project if you need any help.
-- Joost _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
25.11.2010 18:31, A.L.E.C wrote: ...
Thomas is already working on this. Check devel-addressbook branch. We definitely will need a help with LDAP related part.
I can help with schemas, tree representation, indexes, search filters, performance tuning and almost everything else. Unfortunately I currently have no free time to fully dive into development, but can answer any questions. Just don't hesitate to ask.
Best, Vladislav _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
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 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. 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).
- 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?
- 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.
- 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.
- 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.
Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
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
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
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
26.11.2010 18:14, Andreas Dick wrote:
First, I'm definitely for having UUID in a DN instead of name. It's a way more general. ...
- 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'd exploit native LDAP groups for that. I mean:
dn: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server objectType: inetOrgPerson uuid: 1cfeae5f-264e-4b4a-a8e9-efdb259df138 ...
dn: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server objectType: inetOrgPerson (or whatever else that fits, because inetOrgPerson has some drawbacks) uuid: 2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34 ...
dn: cn=Group1,ou=abook,dc=server objectType: groupOfNames cn: Group1 member: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server member: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server ...
Then you can have one contact in multiple groups without object duplication.
Best, Vladislav _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Monday 29 November 2010 09:36:11 Vladislav Bogdanov wrote:
26.11.2010 18:14, Andreas Dick wrote:
First, I'm definitely for having UUID in a DN instead of name. It's a way more general. ...
- 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'd exploit native LDAP groups for that. I mean:
dn: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server objectType: inetOrgPerson uuid: 1cfeae5f-264e-4b4a-a8e9-efdb259df138 ...
dn: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server objectType: inetOrgPerson (or whatever else that fits, because inetOrgPerson has some drawbacks) uuid: 2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34 ...
dn: cn=Group1,ou=abook,dc=server objectType: groupOfNames cn: Group1 member: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server member: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server ...
Then you can have one contact in multiple groups without object duplication.
This is ok for OS-level groups, but not for grouping addresses. How will you be able to integrate this with other Email clients?
Also, why do you want address-entries into multiple groups? I fail to see the use-case for this.
I use webmail when I'm accessing my email from a remote machine, but when I'm at home, I use a desktop email client. I do need to be able to use this client with the LDAP-tree as well.
Additionally, the conventional way of securing the LDAP-tree uses ACLs. Writing ACLs to implement the schema you are proposing will be difficult at best. I can't even begin to think of a way to write them that would allow me to add an address.
-- Joost _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Mon, 29 Nov 2010 10:08:24 +0100, "J. Roeleveld" joost@antarean.org wrote:
On Monday 29 November 2010 09:36:11 Vladislav Bogdanov wrote:
26.11.2010 18:14, Andreas Dick wrote: I'd exploit native LDAP groups for that. [...] Then you can have one contact in multiple groups without object duplication.
This is ok for OS-level groups, but not for grouping addresses. How will you be able to integrate this with other Email clients?
Also, why do you want address-entries into multiple groups? I fail to see the use-case for this.
I play hockey with a co-worker, so I want to have him in two groups: hockey team and after-work-beer group. Anyone with overlaping friend groups will have plenty of similar situations.
I use webmail when I'm accessing my email from a remote machine, but when I'm at home, I use a desktop email client. I do need to be able to use this client with the LDAP-tree as well.
This should be a requirement, for a "propietary" solution we already have RC Address Book. Right now I have some scripting to do RC's mysql to LDAP sync, which is a bad solution.
Regards, haralder _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Monday 29 November 2010 10:44:17 haralder haralder wrote:
On Mon, 29 Nov 2010 10:08:24 +0100, "J. Roeleveld" joost@antarean.org
wrote:
On Monday 29 November 2010 09:36:11 Vladislav Bogdanov wrote:
26.11.2010 18:14, Andreas Dick wrote: I'd exploit native LDAP groups for that. [...] Then you can have one contact in multiple groups without object duplication.
This is ok for OS-level groups, but not for grouping addresses. How will you be able to integrate this with other Email clients?
Also, why do you want address-entries into multiple groups? I fail to see the use-case for this.
I play hockey with a co-worker, so I want to have him in two groups: hockey team and after-work-beer group. Anyone with overlaping friend groups will have plenty of similar situations.
Ok, I tend to use mail-lists for this, but groups as described can be used to generate groups like that. Except that then this method will only be usable from Roundcube and as said, I tend to prefer a desktop client whenever I can.
But "grouping" contacts in LDAP-based addressbooks tend to be mostly based on the fact that there are "global" addresses and "private" addresses.
I use webmail when I'm accessing my email from a remote machine, but when I'm at home, I use a desktop email client. I do need to be able to use this client with the LDAP-tree as well.
This should be a requirement, for a "propietary" solution we already have RC Address Book. Right now I have some scripting to do RC's mysql to LDAP sync, which is a bad solution.
True, and for that requirement to be possible, I do think basing the layout on existing howtos for other products is the easier solution.
If I want to use proprietary solutions, I wouldn't be using Open Source.
-- Joost _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
29.11.2010 11:08, J. Roeleveld wrote:
On Monday 29 November 2010 09:36:11 Vladislav Bogdanov wrote:
26.11.2010 18:14, Andreas Dick wrote:
First, I'm definitely for having UUID in a DN instead of name. It's a way more general. ...
- 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'd exploit native LDAP groups for that. I mean:
dn: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server objectType: inetOrgPerson uuid: 1cfeae5f-264e-4b4a-a8e9-efdb259df138 ...
dn: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server objectType: inetOrgPerson (or whatever else that fits, because inetOrgPerson has some drawbacks) uuid: 2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34 ...
dn: cn=Group1,ou=abook,dc=server objectType: groupOfNames cn: Group1 member: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server member: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server ...
Then you can have one contact in multiple groups without object duplication.
This is ok for OS-level groups, but not for grouping addresses.
This is a way LDAP supports general groups natively, nothing more.
How will you be able to integrate this with other Email clients?
If all other clients in the universe use one standard implementation of LDAP addressbooks, then this way should be used here.
If every developers group reinvents a wheel, then there is no way to be compatible with all others simultaneously.
LDAP data tree is a very configurable, and there is no one common point of view on how data should be stored there. That's why it is very difficult to make implementation to be compatible with all and to be easy to setup.
Look on how simple object can be accessed:
- Direct hit on constructed DN.
- One-level search on specific baseDN with filter.
- Subtree search on baseDN with filter.
- Getall search on subtree with filtering in a client (brain-dead).
And what for groups, I see at least two possible ways to access data.
- GroupOfNames membership
- One-level/subtree search on addressbook branch with filter on
predefined attribute.
Additionally, addressbook data may be placed either in one common branch with additional branching on uid, or under users own object. Or attribute could be added to every object, which specifies whom this object belongs to.
And these are only native ways to do things. Many implementations are broken from the very beginning and try to use LDAP as a relational database. posixGroup/posixAccount is a good example. And it found its way to RFC btw.
Also, why do you want address-entries into multiple groups? I fail to see the use-case for this.
First, because this is supported be SQL addressbook backend. Next, because user may want to (and they do) have one address belonging to several "perpendicular" groups: "Coworkers", "Beer-lovers", "Bike-riders".
I use webmail when I'm accessing my email from a remote machine, but when I'm at home, I use a desktop email client. I do need to be able to use this client with the LDAP-tree as well.
See above.
Additionally, the conventional way of securing the LDAP-tree uses ACLs. Writing ACLs to implement the schema you are proposing will be difficult at best. I can't even begin to think of a way to write them that would allow me to add an address.
Even if you move that branch under user's own DN? I mean something like that: dn: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=AddressBook,uid=blablabla,ou=People,dc=example,dc=com
OpenLDAP allows very flexible wildcard ALCs.
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Mon, 29 Nov 2010 12:00:49 +0200, Vladislav Bogdanov wrote:
29.11.2010 11:08, J. Roeleveld wrote:
On Monday 29 November 2010 09:36:11 Vladislav Bogdanov wrote:
26.11.2010 18:14, Andreas Dick wrote:
First, I'm definitely for having UUID in a DN instead of name. It's a way more general. ...
- 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'd exploit native LDAP groups for that. I mean:
dn: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server objectType: inetOrgPerson uuid: 1cfeae5f-264e-4b4a-a8e9-efdb259df138 ...
dn: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server objectType: inetOrgPerson (or whatever else that fits, because inetOrgPerson has some drawbacks) uuid: 2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34 ...
dn: cn=Group1,ou=abook,dc=server objectType: groupOfNames cn: Group1 member: uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=abook,dc=server member: uuid=2f0f77b4-7d4b-410e-8d5e-d4ee9782ab34,ou=abook,dc=server ...
Then you can have one contact in multiple groups without object duplication.
This is ok for OS-level groups, but not for grouping addresses.
This is a way LDAP supports general groups natively, nothing more.
How will you be able to integrate this with other Email clients?
If all other clients in the universe use one standard implementation of LDAP addressbooks, then this way should be used here.
If every developers group reinvents a wheel, then there is no way to be compatible with all others simultaneously.
LDAP data tree is a very configurable, and there is no one common point of view on how data should be stored there. That's why it is very difficult to make implementation to be compatible with all and to be easy to setup.
Look on how simple object can be accessed:
- Direct hit on constructed DN.
- One-level search on specific baseDN with filter.
- Subtree search on baseDN with filter.
- Getall search on subtree with filtering in a client (brain-dead).
And what for groups, I see at least two possible ways to access data.
- GroupOfNames membership
- One-level/subtree search on addressbook branch with filter on
predefined attribute.
Additionally, addressbook data may be placed either in one common branch with additional branching on uid, or under users own object. Or attribute could be added to every object, which specifies whom this object belongs to.
And these are only native ways to do things. Many implementations are broken from the very beginning and try to use LDAP as a relational database. posixGroup/posixAccount is a good example. And it found its way to RFC btw.
Also, why do you want address-entries into multiple groups? I fail to see the use-case for this.
First, because this is supported be SQL addressbook backend. Next, because user may want to (and they do) have one address belonging to several "perpendicular" groups: "Coworkers", "Beer-lovers", "Bike-riders".
I use webmail when I'm accessing my email from a remote machine, but when I'm at home, I use a desktop email client. I do need to be able to use this client with the LDAP-tree as well.
See above.
Additionally, the conventional way of securing the LDAP-tree uses ACLs. Writing ACLs to implement the schema you are proposing will be difficult at best. I can't even begin to think of a way to write them that would allow me to add an address.
Even if you move that branch under user's own DN? I mean something like that: dn:
uuid=1cfeae5f-264e-4b4a-a8e9-efdb259df138,ou=AddressBook,uid=blablabla,ou=People,dc=example,dc=com
OpenLDAP allows very flexible wildcard ALCs.
As I understand is the today implementation of RC able to read such addressbooks allready...(?) On the other hand, is it as well possible to create/move entries out of RC in a such setup? How can RC get new UUIDs for new contacts? And how can RC handle (add/del/move) groups then? -> this is what I need and what I will try to implement first for an easy LDAP situation: groups with subdirs, which in my opinion can be read out of every client out there....(?)
do you agree?
Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
01.12.2010 09:15, Andreas Dick wrote: ...
As I understand is the today implementation of RC able to read such addressbooks allready...(?)
Ahm, I do not know, this is to core devs.
On the other hand, is it as well possible to create/move entries out of RC in a such setup?
As long as the same schema is used for that contacts. This is mainly about UI representation, just because showing LDAP objects in a general way like most LDAP editors do is always ugly. Anyways, using general LDAP object editor for addressbook is an overkill.
How can RC get new UUIDs for new contacts?
What case do you mean exactly? When RC adds new contacts? Then UUID should be generated by RC. And, of course, it should be first verified that generated UUID does not exist in a directory. There is very small chance that it is already there, and then UUID should be regenerated. If you add contact from outside, then you need to generate that UUID in that tool.
And how can RC handle (add/del/move) groups then?
Do you mean add/delete/move contacts to/from/between groups? You just need to call ldap_modify() on group objects for that. Unfortunately, PHP's implementation of ldap_modify() sucks, you'll need to first read whole list of UUIDs from an object, and then supply whole array of UUID attributes back to ldap_modify(). There is no way to just insert or remove one value of multi-valued attribute, you need to replace all values. I use heavily patched ldap module for my needs which has this fine-grained modify operation, and I'd willing to push changes upstream, but PHP devs community is too unfriendly:
http://sgehrig.wordpress.com/2009/11/06/reading-paged-ldap-results-with-php-...
http://bugs.php.net/bug.php?id=42060
http://sys-net.it/~ando/Download/index.html
After reading that I decided not to even try to push my patches just to save my nerves.
So, I'd better use pure PHP implementation of LDAP operations if one exists.
-> this is what I need and what I will try to implement first for an easy LDAP situation: groups with subdirs, which in my opinion can be read out of every client out there....(?)
Could you please rephrase?
List info: http://lists.roundcube.net/dev/ BT/aba52c80
-
A.L.E.C -
Andreas Dick -
haralder haralder -
J. Roeleveld -
Patrick Nagel -
Vladislav Bogdanov