Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues saving multiple Custom Attachments with certain metadata paths #8

Open
mrblippy opened this issue Mar 4, 2020 · 0 comments
Open
Labels

Comments

@mrblippy
Copy link
Contributor

mrblippy commented Mar 4, 2020

When saving multiple Custom Attachments in the same item the first attachment uploads fine, but any subsequent attachment data gets saved inside the item metadata, instead of the attachment table.

That means only the first attachment will be visible in the item summary.

Based on my testing this will only occur if It is caused when the attachment metadata path is is laid out in a very specific way: /item/{anyNodeName}/attachments/{anyNodeName}

So, for example /item/localData/attachments/resources would cause the bug to happen. As part of my local testing something like /item/charlietest/attachments/charlie would also cause the same bug.

I'm by no means a python or EBI expert, but it seems like

item.getXml().root.getElementsByTagName("item")[0].getElementsByTagName("attachments")[0].appendChild(attachmentElement.root.cloneNode(True))
is at fault.

Steps to reproduce

  1. Import the attached schema and collections into an oEQ institution
  2. Publish an item in the collection
  3. Download the attached .csv file
  4. In the Target column of the csv, replace the uuids with the uuid of your published item
  5. Start the EBI, and import the attached settings file (using the top menu)
  6. Click the 'Start Import' button.
  7. Go to the item in oEQ, notice there is only one attachment, when there should be two.

Files to reproduce issue.zip

@mrblippy mrblippy added the bug label Mar 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant