It would be great to have a destination handler that let us migrate information about workbench on nodes.

I will be providing a patch I wrote.

Other destination handlers for migrate would be great too, but this issue is about filling workbench_access{,_id,_scheme} node data members.

CommentFileSizeAuthor
#11 migrate_destination-1509950-11.patch1.43 KBcatapipper
#9 migrate_destination-1509950-9.patch1.43 KBjoegraduate
#3 0001-Issue-1509950-by-marvil07-Added-Migrate-destination-.patch2.08 KBmarvil07
#1 0001-Issue-1509950-by-marvil07-Added-Migrate-destination-.patch2.41 KBmarvil07

Comments

marvil07’s picture

marvil07 commented
Assigned: marvil07 » Unassigned
Status: Active » Needs review
StatusFileSize
new 0001-Issue-1509950-by-marvil07-Added-Migrate-destination-.patch2.41 KB
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Looks reasonable. A little tough to test....

marvil07’s picture

marvil07 commented
StatusFileSize
new 0001-Issue-1509950-by-marvil07-Added-Migrate-destination-.patch2.08 KB

Well, it seems like the way workbench_access change internally(I was using stable 7.x-1.0 when I worked on the original patch), and now I can not pass workbench_access_id as data member for the node, but instead I can do it with workbench_access. The relevant commits seems to be 2f36e29a7ad1a78d20de1b4716882c44aadf90d1 and 616c257d327994ee967e70b9a5c5ee628d8f5691, where workbench_access_id as data member was removed.

So, this migrate class contains almost no code, since the prepare() is not really required now that workbench_access find the right active tree scheme without help :-)

So, here the re-roll.

marvil07’s picture

marvil07 commented
Status: Needs review » Needs work

I am having some problems still, it seems like the check added on 2f36e29 prevent some(not all) rows to be inserted on workbench_access_node table.

Moving back to NW for now. Suggestions are welcome :-)

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Can you explain the "prevention" described in #4 a little more?

The change you refer to was a patch to align node_load() with node_save() to make migration (and other automated tasks) consistent.

In the migration I did recently, we were using the native taxonomy term fields, which must be configured per content type in order for access rules to be saved. I had to write a small prepare() statement to ensure the $node->workbench_access value was set in those cases.

marvil07’s picture

marvil07 commented

My initial debugging point me to this hunk in the mentioned commit:

-  foreach ($node->workbench_access_id as $id) {
-    $record = array(
-      'nid' => $node->nid,
-      'access_id' => $id,
-      'access_scheme' => $node->workbench_access_scheme['access_scheme'],
-    );
-    drupal_write_record('workbench_access_node', $record);
+  // Load the active tree to get the access scheme data and validate that
+  // the selections are actually present.
+  $active = workbench_access_get_active_tree();
+  foreach ($node->workbench_access as $id) {
+    // Prevent false records from being saved accidentally.
+    if (isset($active['active'][$id])) {
+      $record = array(
+        'nid' => $node->nid,
+        'access_id' => $id,
+        'access_scheme' => $active['access_scheme']['access_scheme'],
+      );
+      drupal_write_record('workbench_access_node', $record);
+    }

So, it seems like I am trying to assign an access_id that is not "active". I am using menu, and the id is a valid mlid.
Still thinking/looking for a solution, but maybe you can tell me how I can make an access id active(In configuration I have workbench_access_auto_assign set to 1).

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Category: feature » support
Status: Needs work » Active

The menu part of this updated code is still buggy -- and you've found the bugs. The problem here may be that the menu item is being saved at the same time the node is -- is that correct? In that case, WA doesn't know what to do with the node yet.

See #1101638: Default menu form support, which is a release-blocker. If you can solve that, then the migration error should solve itself. If you're in a big hurry, use a prepare() method in your migration class to account for the menu id lookup.

I'm going to file this as "support" because it's a known issue that should be supported by the other patch.

marvil07’s picture

marvil07 commented
Category: support » feature

OK, hopefully then the other issue can fix the mentioned problem.

But this issue is about adding migrate support, and IMHO it should live on the module, so back to feature request.

joegraduate’s picture

joegraduate
Primary language English
Location Arizona, USA
commented
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new migrate_destination-1509950-9.patch1.43 KB

Attached is a somewhat simplified version of @marvil07's patch from #3 that should apply cleanly to the latest dev version of Workbench Access. After applying this patch on a site using taxonomy as the Workbench Access scheme, I found that I was able to correctly migrate taxonomy term IDs as workbench access IDs without any problems. I didn't encounter any of the problems described in #6-7.

joachim’s picture

joachim commented
Status: Needs review » Reviewed & tested by the community

Worked great for me.

catapipper’s picture

catapipper
she / they
commented
StatusFileSize
new migrate_destination-1509950-11.patch1.43 KB

For some odd reason the above patch will not work for me and gives no indication other that it doesn't work. I'm going to try rerolling it here and see if that one works.

Ignore my previous comment. I'm having a terrible time trying to use the patch from #9 on workbench_access so that I can use migrate. Any helpful hints for someone doing their site builds via drush make and install profiles?

This is the error I am receiving:

can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/workbench_access.info b/workbench_access.info |index e135037..9edbb24 100644 |--- a/workbench_access.info |+++ b/workbench_access.info -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file b/workbench_access.migrate.inc

catapipper’s picture

catapipper
she / they
commented