ggalmazor
commented
6 years ago @lognaturel, I've ruled out the original strategy I had in mind because it would involve changes in JR (adding a new DataType value for audit fields). I'm right on thinking this is not worth changing JR, right? Could this new AUDIT data type be used for anything else?
Problem description
As explained in #621, when exporting a form that attaches audit information, the audit CSV output files get saved in the media output folder, like any other binary attachments. Since all submissions use the fixed
audit.csvfilename:audit.csv,audit-2.csv,audit-3.csv, etc).Example Audit data
Steps to reproduce the problem
Expected behavior
Instead of having an audit CSV output file per exported submission saved in the media output directory, we want all audit data of the same form to be merged into a single audit CSV output file.
To do so, Briefcase should append a new column to the audit information with the submission UID it belongs to. The resulting Audit Data would look like this:
This way, all audit data of submissions from the same form could be cleanly merged to produce a single output file.
The proposed filename would follow this template:
{FORM NAME} - audit.csv.Other information
Audit information is mapped with a binary binding, which is exported by Briefcase by writing their corresponding file names and, as a side-effect, by copying the media files from the storage directory to the media output directory.
~A strategy to implement the proposed behavior would be to change
Model.getDataType()to consider not only the field's bound data type, but also the field's name and ancestry (meta.audit) to return a newDataType.AUDITthat could be mapped into a newCsvFieldMapperthat would write the same values to the output CSV files and append the audit file's contents to the new proposed output file.~ This strategy is not a good idea because it would involve adding a new DataType in JR, although the new mapper concept is still valid.This mapper could take care of: