Bug #3319
closed
Edit feature doesn't work on documents with uneditable fields
Added by Shaun Walbridge almost 16 years ago.
Updated over 15 years ago.
Description
Continuation of the problem mentioned in #2644: Documents uploaded through Morpho can't be edited through the web form. Simple cases of multiple keywords now work, but other more complex fields do not, particularly for organizations with customized forms. An example invalid document:
http://dev.nceas.ucsb.edu/knb/metacat?action=read&qformat=nrs&docid=bowdish.900.2
To truly fix this, the Registry will need to support the same sophistication of EML as Morpho, which is unlikely in the short term. This is a placeholder bug for the smaller issues such has multiple keywords which can be tackled (i.e. exposed in the UI, just need to serialize the data properly to the form).
Files
The edit feature does not work when keywords are added to the online form. After saving a data package using the online form it is not possible to edit it if keywords are added. I have attached a data package that had this problem. The response is that you used a keyword which can not be edited so use Morpho.
Another related issue is that with the ESA site is that the creator of the data package does not have the rights to save up using Morpho.
Confirmed that multiple keywords did not work. Fixed in latest revision, the only form element which is in the registry form but should cause failure at the moment is additional files, which create <additionalMetadata> elements the form is currently unable to parse.
People need to be able to go back and upload a table, using the NCEAS online form after submitting the data set.
Tentatively planning to fix the upload fields for 1.9. Perhaps the simplest solution is to reuse the upload machinery by pointing the script at the existing data files on disk for SHA1 et al calculations.
This information combined with the metadata should allow us to avoid adding additional fields for POSTing between form submission steps, perhaps with a single additional flag of 'ondisk' for tracking pre-existing uploads.
When parsing existing EML documents, we need to determine if they're 2.0.* documents or 2.1.0; in the former case, first convert the document to 2.1.0 so that we only have to maintain one parser.
Completed fix for modifying documents with otherEntity objects in r4744. The deletefile array generated by the entryForm javascript is passed on to the confirmation stage, and all information about the existing docids is passed on through the 'uploadname' elements, e.g. ondisk:nceas.20.1:4ed2278b77325084c47da85dc4b59c44d8edb1e4. The first flag lets us know the file is an existing element, not a new upload, the second is docid with revision, and the third is the SHA1 sum of the file (which is easier to pass on than regenerate).
This data is then used to syncronize the EML document with our form state. One outstanding issue:
Before the document is commited, we need to decide whether to include the relevant metadata for the otherEntity objects. If the document turns out to be invalid (which we can't detect until insertion) this can cause the data to be 'orphaned', to still exist on disk and in Metacat but not referenced in any metadata document.
Original Bugzilla ID was 3319
Also available in: Atom
PDF