Project

General

Profile

Bug #3319

Edit feature doesn't work on documents with uneditable fields

Added by Shaun Walbridge over 12 years ago. Updated almost 12 years ago.

Status:
Resolved
Priority:
Normal
Category:
registry
Target version:
Start date:
05/23/2008
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
3319

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).

esa.2.2.xml (4.22 KB) esa.2.2.xml Callie Bowdish, 05/30/2008 03:52 PM

Related issues

Blocks Metacat - Bug #2644: The edit feature in the NCEAS Data Repoistory does not workResolved11/06/2006

History

#2 Updated by Callie Bowdish over 12 years ago

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.

#3 Updated by Shaun Walbridge over 12 years ago

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.

#4 Updated by Callie Bowdish over 12 years ago

People need to be able to go back and upload a table, using the NCEAS online form after submitting the data set.

#5 Updated by Shaun Walbridge about 12 years ago

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.

#6 Updated by Shaun Walbridge almost 12 years ago

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.

#7 Updated by Shaun Walbridge almost 12 years ago

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.

#8 Updated by Redmine Admin over 7 years ago

Original Bugzilla ID was 3319

Also available in: Atom PDF