Closed (won't fix)
Project:
LDAP integration
Version:
6.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
10 Jan 2011 at 20:11 UTC
Updated:
8 Mar 2012 at 21:49 UTC
Jump to comment: Most recent file
Comments
Comment #1
imrook commentedI have done some work on this and am posting my results. Attached is a patch with a new module update, 6002, that attempts to migrate columns from the D5 names and format to D6. In addition to different column names, I found that the D6 version of the module serializes multi-line values, whereas the D5 version stored raw text in the database. I have tried to make the update as smart as possible to wind up with a good working configuration at the end. For the fields in question, it checks to see if the old column exists, if so it uses db_change_field() to change the column name and type (This fixes [#3932442] for users upgrading from D5.) It next checks if the field has any newline characters and if so creates an array, serializes it and updates the database with the serialized value.
If the old column did not exist, the module checks to see if the new one already exists. If it does not, the module creates column using the new schema. If the new column already exists a message is displayed to the user. I'm not sure if it's even possible to wind up here, but I want to ensure that the schema is 100% correct by the end of the updates and the user doesn't see any errors whether they are actual problems or not.
I have ran updates several times using the attached patch and my LDAP config come through flawlessly, but I haven't tested all the various config options as I don't have time. I hope this helps smooth out D5->D6 upgrades for others and makes it's way into the module soon.
Comment #2
cgmonroe commentedMarking this as won't fix, since 5 is dead and this is old, Re-open is you think it's still needed.