Tags sometimes move sometimes don't move from Group Library to My Library when copying items
I have two items I have moved from GL to ML, for one tags moved, for the other tags did not move.
Some tags do move, and for some items, only some of the tags move.
I'm a little confused here, as I'm expecting that ALL tags on an item will move when it is moved from GL to ML, and here I see three different behaviors.
This is not what I would expect, which is that all the tags would move, always.
So:
Item 1:
tag 1
tag 2
tag 3
Item 1 all three tags move.
Item 2
tag 1
tag 4
tag 5
Item 2, no tags move.
Item 3
tag 1
tag 2
tag 3
tags n...
Item 3, tags n... move, tags 1-3 do not.
All three were moved via drag-and-drop on the PC desktop client (latest beta).
Some tags do move, and for some items, only some of the tags move.
I'm a little confused here, as I'm expecting that ALL tags on an item will move when it is moved from GL to ML, and here I see three different behaviors.
This is not what I would expect, which is that all the tags would move, always.
So:
Item 1:
tag 1
tag 2
tag 3
Item 1 all three tags move.
Item 2
tag 1
tag 4
tag 5
Item 2, no tags move.
Item 3
tag 1
tag 2
tag 3
tags n...
Item 3, tags n... move, tags 1-3 do not.
All three were moved via drag-and-drop on the PC desktop client (latest beta).
In a future version, you'll be able to update previously dragged items by dragging again.
None of the three items were already existing.
I also emptied the trash prior to copying, as I'd read that could be an issue.
As long as you have "Tags" enabled for copying between libraries in the General pane of the preferences, there's really no reason I can think of why some tags wouldn't be copied other than if the items already exist in the target library. I think you'll find that if you create a new test item and add tags to it, they're reliably copied when you drag the item to another library.
If you really think this is happening, could we see a Debug ID for a drag for a non-previously-dragged item that doesn't copy tags?
The workflow I was using was
1. Search for item to be copied.
2. Delete if found.
3. Copy item.
4. Restore from trash if existed
5. Merge items.
Again, if you think this is happening, we'd need a Debug ID.
I did determine the cause of one of the cases above. For Item 3, it appears that if you don't search for a copy first, and just drag and drop, Zotero fails to copy the item from GL in the target collection, but silently adds the ML copy of the item to that collection, which makes it look like some of the tags have been left out.
That should probably be filed as another bug, as I can't imagine anyone would actually want that functionality...
I'll do some more testing a little later when I have some time.
It sounds like you may be confusing "libraries" and "collections".
As I say, in a future version, you'll have the option of updating the metadata on the item in the target library when dragging again.
What you didn't address was copying the ML version to the target collection, which makes it appear like the copy has succeeded, although it has not.
No one would want this functionality, it's a bug.
Is there an estimate on when this future version will be out?
I've been using the PDF notation functionality, and it's generally terrific. It's become my go-to workflow, despite the limitations and the beta status.
I don't know when exactly that will happen, but it's a fairly high priority.