Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
migration system
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
6 May 2014 at 22:16 UTC
Updated:
29 Jul 2014 at 23:36 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
ultimikeComment #2
ultimikeI made some progress on this one today.
I've attached a patch with the fix for this, I added a static_map process plugin to the d6_user_profile_field plugin that sets the datetime_type to "date" (as opposed to the default "datetime") when migrating a D6 profile "Date" field. The only thing about this patch that bothers me a little is the fact all migrated profile fields are going to have a "datetime_type" settings (all will be set to '' except for migrated "Date" fields). Is this cool?
I am unable to determine why the existing MigrateProfilesTest passed prior to this fix, and am unable to modify the test to produce a failing test...
-mike
Comment #3
chx commentedWell, if we can't fail a test then that's problematic. Also, if this is necessary we should a custom plugin so that only the relevant type gets the setting.
Comment #4
ultimikeI think the issue with the non-failing test is that the value is migrated just fine, but since the D8 form widget is expecting a date and a time, and we're only migrating a date, the D8 display widget doesn't display a value (see this screenshot from a manual test I just ran: http://note.io/UYlf7b).
The MigrateProfileValuesTest test passes because the migrated value in the DB is exactly what is should be.
I'm thinking that I need to modify the MigrateUserProfileFieldTest to ensure we have the correct form widget type. I'll work on that next.
As for breaking the datetime_type into a separate plugin, I'll look at that after I get a failing test working.
Thanks,
-mike
Comment #5
ultimikeWell, creating a failing MigrateUserProfileFieldTest was easy. Patch attached.
Custom plugin coming later.
Thanks,
-mike
Comment #6
ultimike@chx,
Before I start writing code, please let me know if this is what you're thinking...
I'm going to write a new d6 process plugin called Drupal\migrate_drupal\Plugin\migrate\Process\d6\ProfileFieldSettings
The configuration will look something like:
The transform() method will then just have a switch() statement that will set settings.datetype_type to "date" when type = datetime.
Am I missing anything?
Thanks,
-mike
Comment #7
chx commentedSounds right to me.
Comment #8
ultimike@chx - thanks for the help.
I've attached a patch that hopefully fixes this issue. The new test passes (consider the patch in 5 the "FAIL" patch) and a manual test looks good as well.8
Thanks,
-mike
Comment #9
benjy commentedI tested this patch manually and it fixes the issue. With the patch applied I successfully migrated date fields from D6 and the widget on the D8 user/edit page was simply date and not datetime.
I also commented out the fix and ran the tests and can confirm that the MigrateUserProfileFieldTest now catches this issue.
Comment #12
benjy commentedBack to RTBC, looks like some network issues caused the failures: https://www.drupal.org/node/2298415
Comment #13
alexpottComment #14
pushpinderchauhan commentedRerolled patch.
Comment #16
benjy commentedFixed the indent error from #14 and removed the message on the assertion which made this easier to debug.
Comment #17
ultimikeThe re-roll looks fine to me, all minor changes that don't affect the overall patch logic.
Thanks,
-mike
Comment #18
alexpottCommitted 35458b5 and pushed to 8.x. Thanks!