Improvements/code review for XML validation
Hi Koosum
The following functions for the XML validation step are all versions of the existing update function in /xpub-model/entities/manuscript/index.js
static async updateErrorMsg(id, errorMsg) {
const manuscriptUpdated = await Manuscript.query()
.patch({ formState: errorMsg, status: 'xml-triage' })
.where('id', id)
return manuscriptUpdated
}
static async updatePdfDepositState(id) {
const manuscriptUpdated = await Manuscript.query()
.patch({ pdfDepositState: 'WAITING_FOR_PDF_CONVERSION' })
.where('id', id)
return manuscriptUpdated
}
static async clearFormState(id) {
const manuscriptUpdated = await Manuscript.query()
.patch({ formState: '' })
.where('id', id)
return manuscriptUpdated
}
These three functions can all be removed from xpub-model/entities/manuscript/data-access.js
.
If you change this line in xml-validation index const Manuscript = require('../xpub-model/entities/manuscript/data-access')
to const Manuscript = require('../xpub-model/entities/manuscript')
Then instead of these functions you could call e.g.
Manuscript.update({ id: manuscriptId, formState: errorMsg, status: 'xml-triage' }, user.id)
Manuscript.update({ id: manuscriptId, pdfDepositState: 'WAITING_FOR_PDF_CONVERSION' }, user.id)
Manuscript.update({ id: manuscriptId, formState: null }, user.id)
// Note the cleared formState should be set to null, not a blank string
This would solve a problem we are having with columns changing or registering as updating that do not actually need to (part of #475 (closed)), as the existing update function automatically checks the sent value against the previous value and does not change columns needlessly.
Additionally instead of const user = await getUser.getAdminUser()
, the xml-validation utility should use the tagger user for the first upload, or the user who clicks the "regenerate previews" button thereafter, not a random admin user. I believe the tagger user is now seeded and available for this purpose but please ask Nikos and/or Rakesh about it if you find this is not the case!
I have not looked into your use of the File entity in depth, but you might want to check as well the functions you call from xpub-model/entities/file/data-access.js
against those available in xpub-model/entities/file/index.js