Importing a collection results in subcollection contents ending up in collection root

HaroldTheWombat
Dear Zotero people,
Firstly, nice app and I've managed to get a few other people to use it. Sorry for the length of this, I just wanted to get everything down.

I'm in the process of sorting out a decent sized collection of pdf books, notes, papers, patents, etc etc and managed to get myself in a bit of a tangle between my desktop machine and laptop. I've bit the bullet and decided to have the desktop as the authoritative and get sync working for Lappy but I need everything tidied up first.

This is where the problem is. I have the data on Lappy broken down into multiple collections and subcollections. I now want to move the collections, and their subcollections, one at a time over to the desktop. I select one of the collections and export it, right click on collection and "Export Collection...". I provide a path and an export name and off it goes to a memory stick.

The memory stick is then taken to the desktop and I do File -> Import Collection, navigate to the memory stick and select the previously exported collection. Zotero thinks for a bit, and imports the collection.

I now go to the newly imported collection and to my dismay see that all of the entries that were in subcollections are now also in the root of the collection. They still exist in their respective subcollections but are now also in the root.

As you can imagine, this now needs a fair bit of post-processing, deleting all the dupes. I can't just select everything in the root and hit "remove from Collection" as there are entries that should be in the root.

This is very easy to replicate. Just select a collection with subcollections, export into a temp dir giving it a new name then reimport into Zotero.

I don't know if I've missed something in my understanding of the import/export process or if this is a bug/feature. Any thoughts greatly appreciated.

Andrew
  • adamsmith
    That's Zotero RDF?
  • HaroldTheWombat
    Are you asking if I'm using RDF? IF so, my steps are as follows, just as I outlined to recreate the problem:

    Select Collection to export
    Right click on it in the LHS panel
    Select "Export Collection..."
    Dialogue pops up:
    Zotero RDF
    Export Notes
    Export Files
    selected
    Hit OK
    File requester dialogue pops up. Name of exported data -> "trout". Drop into temp dir
    In the same instance of Zotero select File -> Import...
    I want to import from "A file (BibTeX........etc.)"
    Hit Next, a File Import dialogue pops up.
    Navigate to the trout dir, enter the dir and select trout.rdf. Hit Open
    Options dialogue
    Default ticked "Place imported..."
    File Handling is "Copy files...."
    Next
    Import dialogue pops up with "Importing" and a progress bar. Eventually the import completes with an item count which looks about right.
    Hit finish to dismiss the dialogue.
    Now within Zotero navigate to the trout collection.
    Items that were in the subcollections of the Source collection are now, within trout, both in their correct subcollection but ALSO in the root of trout.

    Forgot to mention this before, 9.0.6, 64 bit, up to date Gentoo Linux. Whilst getting the version, I noticed the "Report Errors..." option. Following is the data:

    ***********************************

    1786457867889 addons.xpi WARN Force scan SCOPE_APPLICATION (app-builtin-addons location missing from XPIStates)

    [JavaScript Error: "NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsICommandLine.handleFlagWithParam]" {file: "resource:///modules/BrowserContentHandler.sys.mjs" line: 479}]
    bch_handle@resource:///modules/BrowserContentHandler.sys.mjs:479:34


    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "Zotero.Attachments.cleanAttachmentURI() is deprecated -- use Zotero.Utilities.cleanURL"]

    [JavaScript Error: "TypeError: can't access property "_sizeToPreferredSize", this is undefined" {file: "chrome://global/content/elements/dialog.js" line: 248}]
    moveToAlertPosition@chrome://global/content/elements/dialog.js:248:9
    onload@chrome://zotero/content/about.xhtml:1:1


    appName => Zotero, version => 9.0.6 (x64), os => Linux 7.1.7-gentoo-dist-bin #1 SMP PREEMPT_DYNAMIC Thu Aug 6 19:08:02 -00 2026, locale => en-US, extensions => ZotMeta (2.0, extension)



  • HaroldTheWombat
    I've just tested this on Win 10 and the problem persists. Next, I'm going to set up a much smaller instance of Zotero and see if it can provide some more insight. Will also do the export & import with debug logging enabled.
  • adamsmith
    I think this is likely a genuine bug, no need to do a ton of testing; -- what's your use case? For most purposes, there are better options than large import/export operations. For one offs, there are workarounds.
  • HaroldTheWombat
    So, some simple testing.
    - Create 6 simple pdf's, problem01.pdf, problem02.pdf......., each file with simply a single line of random text.

    - Create a new base dir for Zotero and fire up Zotero pointing to this dir.

    - Create a new collection -> "firstCollection"

    - Create two sub collections, "sub01", "sub02" under "firstCollection"

    - Drag and drop problem01.pdf and problem02.pdf into "firstCollection"

    - Drag and drop problem03.pdf and problem04.pdf into "firstCollection -> sub01"

    - Drag and drop problem05.pdf and problem06.pdf into "firstCollection -> sub02"

    - Right click on "firstCollection" and select "Export Collection". Navigate to a temp dir and provide a name, "exportTest", for the exported data. Do the export.

    - Import the previously exported data, File -> Import, resulting in a new collection called "exportTest"

    - Review the contents of the imported collection, "exportTest". The original collection, "firstCollection" contained only "problem01.pdf" and "problem02.pdf" in it's root. The recently imported collection, "exportTest" now contains all of the files, "problem01.pdf" -> "problem06.pdf" in it's root. "sub01" and "sub02" in both "firstCollection" and "exportTest" contain the same files as expected.

    This test was done on the latest Zotero and an up to date Gentoo Linux machine.

    Can someone, Adam?, please have a quick try of the above and see if the same results are achieved. It took me about 10 minutes to create this.

    The problem has now shown itself for an Import using both 6 entries and about 180.
    It looks like something is flawed, no idea if it is the original Export or the subsequent Import. I'll have a look at the exported XML.
  • HaroldTheWombat
    edited 1 hour ago
    Looking at the RDF file that is exported, and without knowing the actual schema, and also being an XML novice, it appears well formed and correct. The way it's laid out also looks like how I'd[1] do it. Looks like the problem is in the "Import".

    I suppose I'll file a bug......

    Just read the Issue Tracking stuff on the "source_code" page. Do I create the bug or will someone higher up in the Zotero world do that?

    [1] 30 odd years of technical code monkey experience
Sign In or Register to comment.