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.

CommentFileSizeAuthor
#10 signup_phone.png14.83 KBbtmash

Comments

btmash’s picture

I'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.

btmash’s picture

Giving a status update since I won't be able to work on this till the beginning of February:

  • When the module is installed, it will automatically create an registration bundle named signup_registration. This is for an easier migration process.
  • I am currently creating a field named signup_registration_name to go with it.
  • The registration bundle field is attached to all prior nodes that had signup enabled on them. I haven't started to look at setting up any other information regarding this.
  • The module will use the migrate module for migrating over prior nodes and signups. I have the migration of the nodes almost working. There are a few things that need to get sorted out (what to do about confirmation emails which is its own separate issue) and how to get the prior node date in. I'm not sure how field names change between D6 and D7 (cck to core fields) so moving over the dates may be a bit of a challenge. But aside from that, all other data is migrating over fairly nicely.
  • I need to create the actual user signup_log -> registration migration. This means creating a new destinationHandler for registration and so this will likely involve doing an entity->save(). Anyone with experience in migrate and creating destination handlers helping out would be very much appreciated :)
dpi’s picture

Give this a shot, let me know how you go: http://drupal.org/sandbox/danph/1420398

levelos’s picture

@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.

btmash’s picture

Thanks 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.

btmash’s picture

@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 :)

dpi’s picture

Node dates can be migrated using content_migrate.module, as Signup didn't record these. The code works a charm.

From user info, it almost captures most of what signup had...

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.

btmash’s picture

For 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).

dpi’s picture

which field is holding the 'close date' portion

There 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.

I should basically also capture the phone number since Signup Core comes with that

Signup came with a phone number field? :S Theres nothing in the database table.

registration does not come with is an attended field

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.

btmash’s picture

StatusFileSize
new14.83 KB

Ack, 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.

dpi’s picture

If 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.

btmash’s picture

Great! I'll add that field in then :) Onus will be on user to figure out who gets access and how.

dpi’s picture

Onus will be on user to figure out who gets access and how.

For now. But its the users responsibility to add the field in the first place, hopefully they can manage.

drurian’s picture

Component: Code » Registration Core

Is there a newer version of this migration module? Currently the sandbox is producing errors (including duplicate key entry)

seanberto’s picture

Status: Active » Postponed

Quick 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!!)

seanberto’s picture

Status: Postponed » Active
groovedork’s picture

Any update on this issue?

igorik’s picture

Hi, 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,...)

igorik’s picture

Issue summary: View changes

Remove the hiya and get to it.

magnus’s picture

I have a lot of signups and signup status logs I need to convert to Drupal 7. Would be great to migrate to entity registration!

primozsusa’s picture

If somebody would need migratedestination class



class MigrateDestinationEntityRegistration extends MigrateDestinationEntity {
    var $entity_type = 'registration';
    var $entity_info = NULL;
    var $entity_key = NULL;

    static public function getKeySchema() {
        return array(
            'registration_id' => array(
                'type' => 'int',
                'unsigned' => TRUE,
                'description' => 'ID of destination registration',
            ),
        );
    }

    static public function options($language, $text_format) {
        return compact('language', 'text_format');
    }

    public function __construct($bundle, array $options = array()) {
        parent::__construct($this->entity_type, $bundle, $options);
        $this->entity_info = entity_get_info('registration');
        $this->entity_key = $this->entity_info['entity keys']['id'];
    }

    public function fields($migration = NULL) {
        $fields = array();
        $type = ucfirst($this->entity_type) . ': ';
        $fields[$this->entity_key] = $type . t('Existing registration ID');

        $fields['entity_id'] = t('<a href="@doc">Entity Id - competititon nodeid</a>');
        $fields['entity_type'] = t('<a href="@doc">Entity type - "node"</a>');
        $fields['count'] = t('<a href="@doc">Count default 1</a>');
        $fields['user_uid'] = t('<a href="@doc">User Id</a>');
        $fields['author_uid'] = t('<a href="@doc">Author id</a>');
        $fields['state'] = t('<a href="@doc">State keys "confirm", "reservation_pyment"</a>');
        $fields['created'] = t('<a href="@doc">Created date</a>');
        $fields['updated'] = t('<a href="@doc">Updated date</a>');
        $fields['is_new'] = t('Option: <a href="@doc">Indicates a new node with the specified nid should be created</a>',
            array('@doc' => 'http://drupal.org/node/1349696#is_new'));

        // Then add in anything provided by handlers
        $fields += migrate_handler_invoke_all('Entity', 'fields', $this->entityType, $this->bundle, $migration);
        $fields += migrate_handler_invoke_all('Registration', 'fields', $this->entityType, $this->bundle, $migration);

        return $fields;
    }

    public function bulkRollback(array $ids) {
        migrate_instrument_start('registration_delete_multiple');
        $this->prepareRollback($ids);
        node_delete_multiple($this->entity_type, $ids);
        $this->completeRollback($ids);
        migrate_instrument_stop('registration_delete_multiple');
    }

    public function import(stdClass $entity, stdClass $row) {
        $migration = Migration::currentMigration();
        $type = $this->entity_info['entity keys']['bundle'];
        $entity->$type = $this->bundle;
        list($id, $vid, $bundle) = entity_extract_ids($this->entity_type, $entity);

        // Updating previously-migrated content?
        if (isset($row->migrate_map_destid1)) {
            // Make sure is_new is off
            $entity->is_new = FALSE;
            if (isset($id)) {
                if ($id != $row->migrate_map_destid1) {
                    throw new MigrateException(t("Incoming id !id and map destination id !destid1 don't match",
                        array('!id' => $id, '!destid1' => $row->migrate_map_destid1)));
                }
            }
            else {
                $entity->{$this->entity_key} = $row->migrate_map_destid1;
            }
        }
        if ($migration->getSystemOfRecord() == Migration::DESTINATION) {
            if (empty($id)) {
                throw new MigrateException(t('System-of-record is DESTINATION, but no destination id provided'));
            }
            $old_entity = entity_load_single($this->entity_type, $id);
            if (!isset($entity->created)) {
                $entity->created = $old_entity->created;
            }
            if (!isset($entity->uid)) {
                $entity->uid = $old_entity->uid;
            }
        }

        // Invoke migration prepare handlers
        $this->prepare($entity, $row);

        // Trying to update an existing entity
        if ($migration->getSystemOfRecord() == Migration::DESTINATION) {
            // Incoming data overrides existing data.
            foreach ($entity as $field => $value) {
                $old_entity->$field = $value;
            }
            // Use the loaded entity from now on.
            $entity = $old_entity;
        }
        else {
            // Create a full profile class.
            $entity = entity_create($this->entity_type, (array) $entity);
        }

        if (empty($id) && !(isset($entity->is_new) && $entity->is_new)) {
            $updating = TRUE;
        }
        else {
            $updating = FALSE;
        }

        migrate_instrument_start('entity_save');
        entity_save($this->entity_type, $entity);
        migrate_instrument_stop('entity_save');

        list($id, $vid, $bundle) = entity_extract_ids($this->entity_type, $entity);

        if (isset($id)) {
            if ($updating) {
                $this->numUpdated++;
            }
            else {
                $this->numCreated++;
            }

            $return = array($id);
        }
        else {
            $return = FALSE;
        }

        $this->complete($entity, $row);
        return $return;
    }

}

john.oltman’s picture

Status: Active » Closed (outdated)