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

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.

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.

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.

Status:Active» Closed (won't fix)

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

Issue summary:View changes

Spelling mistake.