What about a feature to move fields from one entity to another? Use case example -- fields were created on nodes using content profile in D6, I want to move them to either the user or a Profile 2 entity in D7. The field data is migrated fine and ends up on a D7 node, just need a way to switch the entity the fields are associated to (see http://drupal.org/node/560324#comment-4817254).

Another use case -- I have a bunch of populated image nodes and now would like to use media module and move the field data to a media entity from a node entity.

No code to provide at this point, but it should be possible.

Comments

KarenS’s picture

Version: » 7.x-1.x-dev

This never got assigned a version, so fixing that. I may need this to upgrade D6 Content Profile to D7 Profile 2, using the method I suggested in http://drupal.org/node/560324#comment-4817254 and http://drupal.org/node/560324#comment-5278166, i.e. do the normal D6 to D7 upgrade which will leave me with my profile fields on nodes, then move those fields to a Profile 2 profile.

I can't be sure I will get to this, but a feature like this could be very useful for this and other use cases.

KarenS’s picture

Actually this would also make it possible to move the Content Profile fields to either the User entity or a Profile 2 entity. Something like:

1) Upgrade normally. You will end up with content profile fields on nodes.
2) Use Field tools to clone the fields from the old profile node to either the profile 2 entity or the user entity to create a place for the data to go.
3) If the entities don't already exist (like Profile 2 entities), create them, using the old values, in a batch process.
4) If the entities already exist (like the User), identify the field on the source that maps to the id of the new entity, load the entity, add the values, and save it, also in a batch process.

So this functionality needs a way to identify the source entity/bundle, the new entity bundle, the field on the source that maps to the new entity, if the entity already exists, or an indication that a new entity should be created from the source. Then a batch process to do the actual update.

joachim’s picture

This was discussed at a recent Party/CRM code sprint, and I forgot this issue had been filed.

I wrote a spec here of how this might work: #1602696: field mover module. Creating new entities on the fly is something I hadn't thought of, which certainly has a use case :)

I think it perhaps should be its own module rather than live here.

q0rban’s picture

Status: Active » Closed (won't fix)

Hmm, I guess that makes this "won't fix".

q0rban’s picture

Issue summary: View changes

Spelling mistake.

frob’s picture

Issue summary: View changes
Status: Closed (won't fix) » Active

I am switching this back to active, more than one module can live in a project and I think even though this feature should be its own module it should be in the field_tools project.

nwoodland’s picture

In case anyone comes across this thread like did and finds this useful, I had a need to move a bunch of fields from a paragraph type to a node type in Drupal 8, and I used this quick and dirty code to accomplish that (only caveat is I needed to manually set the form and display configs for these fields, though I'm sure that could've been automated as well):

    $poc_fields = [
      'field_adl_iadl',
      'field_asa_referrals',
      'field_authorized_for_lifeline_se',
      'field_backup_plans',
      'field_care_coordination_sec_12',
      'field_care_coordination_sec_19',
      'field_cf_poc',
      'field_choice_letter',
      'field_dhhs_roi',
      'field_dhhs_roi_attachments',
      'field_eligibility_letter',
      'field_hbc_copayment',
      'field_hbc_waiver_of_copayment',
      'field_health_welfare',
      'field_job_description',
      'field_medical_records_roi',
      'field_orc_hours_budget',
      'field_payroll_data_sheet',
      'field_person_center_plan',
      'field_plan_of_service_agreement',
      'field_pre_post_test',
      'field_privacy_policy_consent',
      'field_risk_mitigation',
      'field_rn_assessor_notes',
      'field_rn_referral',
      'field_skills_training_hours_budg',
      'field_wsp_referral',
    ];

    foreach ($poc_fields as $poc_field) {
      $field_storage_source = \Drupal\field\Entity\FieldStorageConfig::loadByName('paragraph', $poc_field);
      $field_source = \Drupal\field\Entity\FieldConfig::loadByName('paragraph', 'plan_of_care_year', $poc_field);
      // Field storage:
      $field_name = $field_storage_source->getName();
      $field_type = $field_storage_source->getType();
      $field_storage_settings = $field_storage_source->getSettings();
      // Field:
      $field_label = $field_source->getLabel();
      $field_settings = $field_source->getSettings();

      \Drupal\field\Entity\FieldStorageConfig::create([
        'field_name' => $field_name,
        'type' => $field_type,
        'entity_type' => 'node',
        'settings' => $field_storage_settings,
      ])
      ->save();

      \Drupal\field\Entity\FieldConfig::create([
        'field_name' => $field_name,
        'entity_type' => 'node',
        'bundle' => 'enrollment',
        'label' => $field_label,
        'settings' => $field_settings,
      ])
      ->save();
    }
colan’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev

New features go into HEAD, and can then be backported if there's interest.

Anybody’s picture

Still makes sense to either disallow to copy a field from one entity type to another OR (even better) copy it over correctly.

joachim’s picture

This is getting confusing -- the IS is talking about moving DATA, but the code in #6 is showing moving FIELD DEFINITIONS.

For moving data -- use Migrate. Out of scope for this module.

For moving field definitions -- I'll take a patch :)

Anybody’s picture

@joachim: Would you agree with my point in #8?

Still makes sense to either disallow to copy a field from one entity type to another OR (even better) copy it over correctly.

It's quite dangerous, if someone clones a field across entity types currently, isn't it?
I suggest only showing current entities fields, until this is properly implemented

If you agree, I'll provide a patch for that until someone has the time to fully implement support for that.

Anybody’s picture

Update: I created a separate issue for that now: #3345004: Cloning to other entity type bundles should not be allowed, until it's supported would appreciate a short feedback @joachim before I start with the implementation.

joachim’s picture

> It's quite dangerous, if someone clones a field across entity types currently, isn't it?
I suggest only showing current entities fields, until this is properly implemented

It should be fine, but you have to:

a. check the field name isn't already used on the destination entity type
b. clone the field storage as well as the instances

Anybody’s picture

Thanks @joachim!! :) So this issue can still be used to implement the full support!

joachim’s picture

Status: Active » Closed (won't fix)

Ok.

I'm going to put this issue to wontfix, since you're working on the new one, and this issue's summary is about field data, which Field Tools isn't going to support.