Context
Bulkrax field mappings can be flagged generated: true to indicate that the field is system-maintained (e.g. date_uploaded, depositor, source, admin_set_id) or auto-renderable (e.g. rights_statement, abstract). Host apps like Hyku use this flag broadly in their default Bulkrax::CsvParser mappings.
The downloadable CSV template currently hides every generated: true mapping so users don't see those columns on import. But that's a blunt rule: some generated: true mappings are perfectly valid import columns (e.g. rights_statement, abstract, alternative_title, import_url), while others are genuinely system-managed and should stay hidden (e.g. date_uploaded, depositor, state, owner).
What the real importer does
The importer itself doesn't consult the generated: flag at all. It accepts any CSV column whose mapping key passes field_supported? — which ultimately checks whether the property is declared on the model's schema or appears in the always-supported list (file, remote_files, rights_statement, parents, children). Columns whose mapping resolves to unsupported keys (e.g. date_uploaded) are silently dropped at import time.
Gap
The current "hide all generated: true" heuristic for the CSV template:
- Correctly hides
date_uploaded, state, owner, etc. (good — these aren't importable in any useful way).
- Incorrectly hides
rights_statement, abstract, import_url, etc. (bad — these are legitimate import columns the user probably wants the template to document).
Suggested enhancement
Replace the generated: true filter in Bulkrax::CsvTemplate::MappingManager / ColumnBuilder with a policy that matches the importer:
- Include a mapping in the template iff its key passes
Bulkrax.object_factory.field_supported?(field:, model:, admin_set_id:) for at least one of the models being documented, OR is in the "always-supported" set.
- Drop the
generated: flag's role in template visibility entirely; keep it for its export-side meaning (exporter's generated_metadata toggle).
Net effect: the template documents exactly the columns the importer would accept, with no per-property guesswork based on a flag that was never designed for import gating.
Related validator enhancement
The guided-import validator currently flags a CSV header as "recognised" if any mapping's from: alias matches. It could be tightened to additionally require field_supported?, giving a useful "column will be silently dropped" warning — matching the stricter template policy above.
Context
Bulkrax field mappings can be flagged
generated: trueto indicate that the field is system-maintained (e.g.date_uploaded,depositor,source,admin_set_id) or auto-renderable (e.g.rights_statement,abstract). Host apps like Hyku use this flag broadly in their defaultBulkrax::CsvParsermappings.The downloadable CSV template currently hides every
generated: truemapping so users don't see those columns on import. But that's a blunt rule: somegenerated: truemappings are perfectly valid import columns (e.g.rights_statement,abstract,alternative_title,import_url), while others are genuinely system-managed and should stay hidden (e.g.date_uploaded,depositor,state,owner).What the real importer does
The importer itself doesn't consult the
generated:flag at all. It accepts any CSV column whose mapping key passesfield_supported?— which ultimately checks whether the property is declared on the model's schema or appears in the always-supported list (file,remote_files,rights_statement,parents,children). Columns whose mapping resolves to unsupported keys (e.g.date_uploaded) are silently dropped at import time.Gap
The current "hide all
generated: true" heuristic for the CSV template:date_uploaded,state,owner, etc. (good — these aren't importable in any useful way).rights_statement,abstract,import_url, etc. (bad — these are legitimate import columns the user probably wants the template to document).Suggested enhancement
Replace the
generated: truefilter inBulkrax::CsvTemplate::MappingManager/ColumnBuilderwith a policy that matches the importer:Bulkrax.object_factory.field_supported?(field:, model:, admin_set_id:)for at least one of the models being documented, OR is in the "always-supported" set.generated:flag's role in template visibility entirely; keep it for its export-side meaning (exporter'sgenerated_metadatatoggle).Net effect: the template documents exactly the columns the importer would accept, with no per-property guesswork based on a flag that was never designed for import gating.
Related validator enhancement
The guided-import validator currently flags a CSV header as "recognised" if any mapping's
from:alias matches. It could be tightened to additionally requirefield_supported?, giving a useful "column will be silently dropped" warning — matching the stricter template policy above.