You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the Field/Table CSV export (for works and collections) assumes that it is being used on document based projects instead of field-based ones. To support wiki-links within the markdown tables, we expand the csv export into a test column for the verbatim links, and a subject column for the canonical subject headers.
Unfortunately, 97% of projects using this export are field-based projects, which do not support subject indexing. For these projects, we should only provide a single column per field/column in the export, containing the text. The column header should just be the field/column label, instead of suffixing (text) onto it.
We could key off the collection settings (subjects_enabled? field_based?), but it's probably easier to test if a transcription_field exists and suppress the subject column if it does.
@benwbrum
What I understood from the description is that I have to add a check which will check if Collection.transcription_fields.present? than instead of @headings << "#{raw_heading} (text)" we need to change it to @headings << "#{raw_heading}" right?
Do let me know is there anything am I missing ?
Currently the Field/Table CSV export (for works and collections) assumes that it is being used on document based projects instead of field-based ones. To support wiki-links within the markdown tables, we expand the csv export into a test column for the verbatim links, and a subject column for the canonical subject headers.
Unfortunately, 97% of projects using this export are field-based projects, which do not support subject indexing. For these projects, we should only provide a single column per field/column in the export, containing the text. The column header should just be the field/column label, instead of suffixing
(text)
onto it.We could key off the collection settings (subjects_enabled? field_based?), but it's probably easier to test if a
transcription_field
exists and suppress the subject column if it does.See relevant code:
The text was updated successfully, but these errors were encountered: