field_resource_type is not being populted using migrate_islandora_csv

[mjordan]

Importing the sample images provided in https://github.com/Islandora-CLAW/migrate_islandora_csv do not get their field_resource_type populated.

[whikloj]

There are no fields in the csv or configs for that field, but we do tag field_model and if that has the "type" then the context should get called as I don't think it cares which field the taxonomy term is in, just that it exists on the object/media.

[whikloj]

@mjordan I think the field_resource_type is the field with the actual "Resource Type" (ie. Image, Interactive Resource, Moving Image), so you could easily add a new field to the CSV if you want.

[mjordan]

@whikloj OK, I've created an additional PR that takes the "Image" resource_type value from the CSV records.

[mjordan]

I am thinking it might be good to provide examples of both approaches (1 -hard-code taxo term in YAML and 2 - provide term string in CSV) in this module so others can figure out how do both. What do you guys think?

[mjordan]

We wouldn't want both approaches to be in play in the config file, so maybe should comment out the example of 1 (hard-coded) in the YAML file and include a comment that if you have a value that applies to all records in your CSV, you can use that approach. For example:

# If you have a taxonomy field that has the same value in all records in your CSV
# file, you can populate that field by hard-coding the term in the YAML configuration
# file, like this (lines are commented out, remove the leading # to uncomment):
#  field_resource_type:
#    plugin: entity_lookup
#    source: constants/resource_type
#    entity_type: taxonomy_term
#    value_key: name
#    bundle_key: vid
#    bundle: resource_types

This could also be documented in the README file.

[seth-shaw-unlv]

Keeping commented-out content in config files is actually quite annoying in the Features import/export workflow. If you import the config all the comments get stripped out. Then, if you export the feature because you made a change to something unrelated, like a view, then it will overwrite your config with the comments with a version without. This requires you to continually discard changes for that particular config to keep comments around when making commits to git.

I recommend keeping comments about configs in external documentation.

[mjordan]

@seth-shaw-unlv thanks for the heads up. I'll open another PR that adds this to the README and close the existing two.

[dannylamb]

Ok to close this one?

[mjordan]

Yup.