(
Jump to the original submission)
Tue 17 Jul 2007 04:34:50 AM UTC, comment #6:
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=328
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=329
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=330
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=331
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=332
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=333
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=334
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=337
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=338
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=340
http://insidedlab.jpl.nasa.gov/internal/tiki/tiki-view_forum_thread.php?topics_offset=1&topics_sort_mode=commentDate_desc&forumId=6&comments_parentId=341
|
Mon 13 Mar 2006 09:52:28 AM UTC, comment #5:
Sorry but i'm very busy now and i'll be so for at least some weeks... so i not will be able to test this... sorry. ;(
|
Sun 12 Mar 2006 12:14:23 PM UTC, comment #4:
Ok,
Here the patch,
Please not that if you apply it, you will need to use it on a plain install if you change one of the $GLOBALS['phpgw_info']['server']['ldap_{user,group}_number'] (in the constructor) ...
DONT DO IT ON A PRODUCTION SERVER and SAVE ALL LDAP DATA !!!
you need to heavily test it :
create account, delete account, idem for groups in all maner you do it (and use calendar too) ...
Dave, I notice that you have done some modifications ... I need that (if possible) you test this patch too, since I modify some search functions ...
Regards,
Caeies
|
Sun 12 Mar 2006 10:47:15 AM UTC, comment #3:
Hi,
Well I found a bigger problem than this one ...
In fact, if I take the history, we need to regress to correct this bug, and I hate this ... But we need to do a choice. Ok here the full story (AFAIK) :
in .14 the ldap was totaly "decorelated" btw ldap itself, and phpgw (hence the schema for phpgroupware) ...
in .16 we (fips and me) worked to make phpgroupware able to use a plain schema for ldap (so posixAccount object etc...) We worked hard for this ... but since we need to take sql accounts limitation (and avoid to break the whole app) we choose to keep some limitations, waiting for the api to evolve ... So we do the choice to be closer than possible from plain ldap.
Your needs oblige me to go back in the past to redo the old work ...
I will shortly propose a patch, and will ask you to test it. Stop me if I'm wrong, but if you are saving a group, I'm quiet sure that you will loose the groupid number if it's not the same as in phpgroupid ...
regards.
Caeies
|
Wed 08 Mar 2006 05:12:09 PM UTC, comment #2:
Ok, probably i was not clear.
All this AFAIK.
If you have to setup a phpgw ldap-enabled setup with an existent ldap setup probably you encounter a trouble: in unix userid space are different from groupid space, so there's uid=1000 and also gid=1000.
To circumvent this, in the ldap schema the phpgwAccountID and the phpgwGroupID attribute was added, that permit a binary relation between gid/uid of LDAP/unix and the ID of phpgw.
But if for user they works (i can have user gaio with uid=1000 and phpgwAccountID=1234, and in phpgw_acl table user gaio are referenced by id 1234), for group no, or at least some application (most notably calendar) complain for id clash even if i've set phpgwGroupID to some free ID.
Hope that now it is clear.
|
Mon 06 Mar 2006 01:13:29 PM UTC, comment #1:
Doing this kill the apps, since there is correspondance btw ACL number and phpgroupLDAPID, If you modify them only in LDAP, then you kill the whole app ...
regards Caeies
|
Mon 27 Feb 2006 02:59:42 PM UTC, original submission:
If there's an ID clash between UID and GID, with this .16 new LDAP schema, i can set phpgwGroupID and phpgwAccountID to some other integer, very cool.
But if for phpgwAccountID seems work well, the phpgwGroupID field in some application (eg, calendar) are totally ignored, and to make calendar work you have to change gidNumber, a real pain sometimes...
|
Depends on the following items: None found
Items that depend on this one: None found
Follow 6 latest changes.