Trying to migrate some polls to a "Closed" state is impossible. I've attached a small patch which should fix the issue, but the documentation needs to be changed to explain that the $row->active value needs to be set to the desired value.

A work around is to add the following code to your migration.

public function complete($entity, stdClass $row) {
        // Update settings overridden by !user_access('administer nodes') check in
        // poll_insert().
        db_update('poll')
          ->fields(array('active' => $row->active))
          ->condition('nid', $entity->nid)
          ->execute();
}
CommentFileSizeAuthor
migrate_poll_always_active.patch565 bytesdaveparrish
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikeryan’s picture

Status: Active » Needs review

Be sure to set the issue status to "needs review" when submitting a patch, both so the testbot picks it up and to flag it for human review.

mikeryan’s picture

Status: Needs review » Needs work
+++ b/plugins/destinations/poll.inc
@@ -83,7 +83,7 @@ class MigratePollEntityHandler extends MigrateDestinationHandler {
+        ->fields(array('active' => $row->active))

Sorry, this is wrong - it might work where your source system (presumably Drupal in your case, I'm guessing) has that value in a field named 'active', but not in the general case. If you've got a field mapping of 'active' to 'active', then the desired value should be in $entity - if it's not, then there's something wrong elsewhere.

daveparrish’s picture

Thank you for the response mikeryan. I thought the same thing, but I noticed that the 'choice' and the 'votes' fields use the '$row' object to get their values. Why is the '$row' object used in those cases?

The comments explain why the '$entity' cannot ever give a value besides '1' for the 'active' field. I cannot think of another solution besides using '$row' or not trying to fix 'active' at all and just setting it in my own complete() function.

Anyway, the current code must be wrong because it always sets the 'active' field to 1 if the migration is run from drush.

// Update settings overridden by !user_access('administer nodes') check in
// poll_insert().
db_update('poll')
  ->fields(array('active' => $entity->active))
  ->condition('nid', $entity->nid)
  ->execute();  // $entity->active == 1

Does that makes sense?

mikeryan’s picture

*Sigh*. Yeah, I let that usage of $row get by when initially committing the contribution, and we're kind of stuck with it as the established API. I don't want to compound the problem, though.

Let's try to figure out the root cause here. 'active' is provided as a destination field in fields(), so

$this->addFieldMapping('active', 'active')

Should set $entity->active to the value of $row->active in the field mapping process. If that's not happening, then there's something wrong somewhere else - let's figure that out rather than using the $row hack.

daveparrish’s picture

If I'm not mistaken the "somewhere else" is in the core Poll module. You can see where the Poll module sets the 'active' value to 1 on line 543 of the poll.module file. http://cgit.drupalcode.org/drupal/tree/modules/poll/poll.module?h=7.x

Is this issue a Drupal core issue then?

mikeryan’s picture

Ah - yes, it's unfortunate that core hard-codes an active value of 1 on creation. The poll module is being removed in D8, so not much point in looking to change it on that end.

OK, so the way to make this work in the normal way (so addFieldMapping works as expected) would be to save $entity->active in prepare(), and apply that value in complete() (much like how the node destination has to save the changed value aside and explicitly set it after node_save() because it's hard-coded to REQUEST_TIME).