When I first initialize a custom migration module, there is nothing listed on the job listing page, but once I register my first task that is assigned to a job (group), the task's group AND a group called 'default' is displayed in the UI.

I would suggest that if all the tasks are assigned to named jobs, then there is no need to display the empty 'default' group in the UI.

Comments

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Title: Do not show 'default' job on the jobs listing page if it has no tasks » "Default" job created when no migration belongs to default
Component: migrate_ui » Code
Category: feature » bug
Status: Active » Postponed (maintainer needs more info)

So, you're registering migrations assigned to a different job, and a "default" job is being created as a result? I would consider that a bug - I was having that issue earlier in the 2.6 development, but I thought I had killed it - haven't seen it in my own development in a while. How are you registering the migrations? I'd like to be able to reproduce this scenario.

JSCSJSCS’s picture

JSCSJSCS commented

I am registering them in hook_migration_api().

The 'default' job is being created in addition to my job registered in the hook.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

Don't forget to reset the status to "active" if you'd like a more timely response - postponed issues are the lowest priority when I'm going through the queue.

Are you setting 'group_name' in the migration arguments when registering your migrations? Methinks this may primarily be a documentation issue, I'll definitely cover it when updating the docs: #1965854: Update documentation for Migrate 2.6.

Lowell’s picture

Lowell commented

This has been a HUGE headache for me too, finally led me here because I have the same "symptoms"

I simply found a "typo" in my .module file.
The $source_fields array in the MigrateDestinationNode [class?] was misspelled.

Finally solved it when I changed Devel error handling to none and the relevant line number was spit out at me on white error page.
With the error handling set to Standard Drupal the error message was suppressed and I had no idea what the trouble was.

A good lesson to learn about error tracking :-)

It might be a good idea to catch this error and show it on the content/migrate page.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Postponed (maintainer needs more info) » Closed (duplicate)

I believe the work I'm doing in #1928956: Straighten out constructor parameters/arguments should prevent the bogus empty default group from being created.