Registry mixes up users when saving
If different users are added for the data set owner and contact, the registry messes up the serialization and takes data from the contact form and saves it into the data set owner fields. Verified on dev.
#1 Updated by Shaun Walbridge over 10 years ago
Further details: Other than the first and last name fields, none of the fields from the section "PRINCIPAL DATA SET OWNER" are reflected in the EML output by the registry. Instead, all the fields are overwritten by data from the "Contact" section, regardless of the "Use the same name and address as the PRINCIPAL DATA SET OWNER above" setting.
All data entered into the 'data set owner' fields should be copied to a //creator element (as the last and first name are currently) instead of copied from the 'contact' data which should be stored only in a //dataset/contact element.
Also of note: currently on esa-dev.nceas.ucsb.edu, the state field is copied from the 'data set owner section' into the 'contact' section, contrary to the statements above (and as tested on dev.nceas.ucsb.edu).
#3 Updated by Jim Regetz over 10 years ago
(In reply to comment #1)
All data entered into the 'data set owner' fields should be copied to a
//creator element (as the last and first name are currently) instead of copied
from the 'contact' data which should be stored only in a //dataset/contact
As tested on dev, I agree the PRINCIPAL DATA SET OWNER first and last names are
the only owner values being preserved in the EML doc, but they're not actually
retained in the creator element. Instead, they end up appearing in an
associatedParty element, like this:
The creator and dataset/contact elements then end up being identical, both populated with the DATA SET CONTACT values.
As Shaun said, esa-dev is behaving differently in that the US State/Province
field (adminstrativeArea in the EML doc) is pulled from the owner information
rather than contact information, and that value then appears in the EML doc in
both the creator and dataset/contact elements.