First off, thank you for pointing me towards the dev branch of entity registration - it helped me get a better idea of the functionality that is coming and pretty much fits in where I had wanted signup to go. I currently use the signup module on one of my sites and am planning to migrate over whatever set of signup data I currently have into entity registration data (which, given that we are now dealing with entities may or may not be a more complex problem). I wanted to open for a few reasons:
- Is there a planned migration path?
- If there is a planned migration path, what needs to be done?
- If there a migration path has not yet been set, could we use this issue as a starting point to lay out the plan?
I figure that if we get some idea of how we want to approach this (use migrate module, straight php/db_insert/update or equivalent drupal functions, etc), it can cut down on any duplicate work for this.
Since we are starting off, I see atleast the following steps that need to be done:
- Figure out global signup settings.
- Based on global signup settings, create registration bundle with the necessary fields (which could be a maximum of email, name, phone number or we just create all 3)
- Create a registration field based off this bundle and attach it to any existing node types that currently have signup enabled.
- For each node with signup data (not including the actual signups), save its equivalent data in entity registration.
- Save the signups from each node to the equivalent structure in entity registration.
Not sure what else I'm missing.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | signup_phone.png | 14.83 KB | btmash |
Comments
Comment #1
btmash commentedI've created a sandbox for the module at http://drupal.org/sandbox/btmash/1415816 just so I can start playing around with how the content comes in. Nothing is done yet but I'll see where it gets.
Comment #2
btmash commentedGiving a status update since I won't be able to work on this till the beginning of February:
Comment #3
dpiGive this a shot, let me know how you go: http://drupal.org/sandbox/danph/1420398
Comment #4
levelos commented@btmash and @dpi, just wanted to say a big thanks for the signup migration efforts. When these are flushed out / ready to go, we'll definitely promote them as an upgrade path in the project description and docs.
Comment #5
btmash commentedThanks for you work, @dpi. I'll def. check it out what you have written (I've briefly looked at the code and I like some of your ideas though I'm not entirely sure to go ahead on them or not so I need to look some more though I also know that mine requiring migrate for a migration might be overkill) :) @levelos, any input from you would also be greatly appreciated in terms of direction/whatnot.
Comment #6
btmash commented@dpi, I tried out your codebase and I got a chunk of it working though I was having issues with other parts. So I wrote out a chunk of what was needed via the migration module. At this point...it is almost wholly working. The prior node date portion is still an issue (any help on that from anyone would be helpful) but atleast the status of the registration remaining open, seats, etc is all captured. From user info, it almost captures most of what signup had (I had not created a phone field since I didn't know if we wanted that but name is migrating through as is email, timestamp, number of people). If the folk came is not captured but that was because there is nothing to map to for that. I also need to figure out dependencies in migration (I would like the nodes to map out before migrating in the folk that registered) but otherwise, the data is coming into the tables :)
Comment #7
dpiNode dates can be migrated using content_migrate.module, as Signup didn't record these. The code works a charm.
I think a hook to handle the custom $form values from Signup would be ideal. The code should handle core Signup only, unless a generic solution can be devised for inserting into D7 fields.
Comment #8
btmash commentedFor the date...I know content migrate handles this; do the field names change from 6 to 7? If I get a grasp on which field is holding the 'close date' portion, then adding that to the registration_entity table will be very simple. Ok...maybe not that simple, but easy enough :) I have only been working off signup for Drupal 7 so I know the field names match up on that side :)
Based on your note for handing core signup, I should basically also capture the phone number since Signup Core comes with that. The portion I wrote for the registrationdestinationhandler might be something that makes sense to contribute back to the migrate_extras project. Then folk have the option of writing their own migration handler instead of using what mine offers and can pull in the additional fields as needed.
Now on to portions I am unsure on how to cover: the piece registration does not come with is an attended field (not sure where that fits in). Also the issue on possibly using entityreference will have an issue on what needs to change in this module (hopefully won't be too big).
Comment #9
dpiThere is no 'close registrations on X date' functionality. This functionality could best be done in a third party, or submodule. I have started some work on this. See #1316236: Provide option to set a date to automatically close registration.
Signup came with a phone number field? :S Theres nothing in the database table.
Please see README.txt in my migration module on how to add the attended field. It makes sense for Registration to add this field automatically, however it should implement cores list, or integer or something.
Comment #10
btmash commentedAck, you're right on the closing date thing. Signup has the functionality to close off signups and registration...I'm not entirely sure if it does. But they both have a 'send reminder' field. In signup, that can be based on a date field so if I can figure out a way to get that value, then we have something to work off.
Signup core does have a phone field (attached image) - it stores it in the form_data column (along with the name).
I see you create a field - that makes things a lot simpler (is there a way it gets hidden right now) :) I'll pay closer attention to that portion of your code and hopefully have a chance on Monday to figure out some more stuff.
Comment #11
dpiIf your events are group content (Organic groups) then you can use OG field access to restrict to group owners.
Otherwise: field_permissions, or your own custom code to restrict to whoever.
Hmm, I think the phone may have been more of example code for how you can use the $form values. But if you made use of it, I'm sure something can be worked out.
Comment #12
btmash commentedGreat! I'll add that field in then :) Onus will be on user to figure out who gets access and how.
Comment #13
dpiFor now. But its the users responsibility to add the field in the first place, hopefully they can manage.
Comment #14
drurian commentedIs there a newer version of this migration module? Currently the sandbox is producing errors (including duplicate key entry)
Comment #15
seanberto commentedQuick update, we're fairly close to a stable release of Entity Registrations. This month and next we will be working closely with the COD team to identify any underlying changes to ER that are needed for better COD/Commerce integration.
IMHO, it probably makes sense to hold off on any new, major efforts to provide a migration path from Sign-up to ER, until our next big push is complete. Internally, our team has been quickly writing our own Migrate 2.x classes to handle similar migrations. I know that's not ideal, but we're getting closer.
There's definitely a ton of interest in a point-and-click migration path. Can't wait to see it happen!
(Marking this ticket as postponed to avoid confusion. If any zealous migration lovers out there wants to open it back up and work on something in a sandbox, please feel free!!)
Comment #16
seanberto commentedComment #17
groovedork commentedAny update on this issue?
Comment #18
igorik commentedHi, is there any update about this?
I would really love to migrate signups from d6 into registrations in D7
Did it try someone?
Thanks for the help or inspiration. Maybe hardcode migrate using migrate module and migrate class into some registration field?
Not very optimistic about this, there probably will be not signup settings for relevant nodes (open/closed,...)
Comment #18.0
igorik commentedRemove the hiya and get to it.
Comment #19
magnus commentedI have a lot of signups and signup status logs I need to convert to Drupal 7. Would be great to migrate to entity registration!
Comment #20
primozsusa commentedIf somebody would need migratedestination class
Comment #21
john.oltman commented