Moving item to another group library forces reset of source library

I am a member only of library A and I try to drag and drop an item to copy it into Library B that I am an admin of. It copies it across fine but when I sync it forces a total reset of Library A to the server version.

Any thoughts on the following questions.....

1. Is the system designed to work this way? If so what is the rationale for it since on the surface no changes are made to Library A and the copy goes ahead to Library B anyhow.

2. Is there a work around so I can copy from Library A (member) to Library B (Admin) without having to reset Library A to the server version each time?
  • It doesn't sound like that would be intended, no.
    Do you have permissions to add and edit items in Library A?
    What exactly do you mean by "reset to server version" - what exactly happens?
  • No I don't have permissions to add and edit items in Library A.

    Post the copy of the item from Library A to B what happens is a message comes up saying....

    'You no longer have write access to the Zotero group [Library A].......'. I have never have had write access to Library A though.

    'If you continue [to sync] your copy of the group will be reset to its state on the server and local modifications to items and files will be lost.....'

    There is then the option on the dialogue box to 'Cancel' the sync or 'Reset group and sync'.
  • if you can't edit the library anyway, I don't see the harm in resetting it to the server state?
    Either this is a small glitch or you briefly had edit permissions and changed something small.
    Or have you reset group before and this keeps re-occurring?
  • Library A is a large library that I need to regularly copy items from into my own library. One reset isn't a problem at all, but it takes half and hour to do so if it occurs each time I copy something it is a problem.

    I have never had permissions to write to Library A. I have never reset the group before and a couple of us have been able to recreate this problem using test accounts so the behavior is consistent.

    Why would the system view a copy as trying to write to Library A? Is it because it has to duplicate it in Library A before it is moved?

    And is there be a possible work around so this reset doesn't occur each time I do a copy?
  • I'm still not clear whether you have ever agreed to the reset?
    If you have, this is definitely worth troubleshooting further, but if you haven't you're just seeing the same problem that's never resolved reoccur.
    Why would the system view a copy as trying to write to Library A? Is it because it has to duplicate it in Library A before it is moved?
    it wouldn't. If it does that's a bug, but to understand what's actually going on, we need to understand whether you have actually ever let the reset run.
    And is there be a possible work around so this reset doesn't occur each time I do a copy?
    There is no workaround - either this is a bug that needs to get fixed or it will go away after one successful reset of the group from the server.
  • Thanks adamsmith for your help

    Yes I have reset the group and it does the same thing again.

    We have also created a new test account, synced for the first time and created the problem. So it does unfortunately look like a bug.
  • OK, Dan will have to take this over from here, but let's make sure he has the info he needs. First, the name of the group would be helpful (unless you don't want to put it on the forum).

    Then, turn off auto sync, manually sync once to make sure everything is up to date, then enable debug logging and provide a debug ID that covers both copying an item out of library A and then a manual sync up to the error message. You can cancel the message, no need to run the reset (in fact, better to not do that so the debug isn't too long).
    http://www.zotero.org/support/debug_output
  • That's OK — I think I know what's going on here, so I don't need the debugging info. More soon.
  • This should now be fixed in the latest 4.0 Branch dev XPI. For inter-group drags, we were storing the behind-the-scenes linked-item relation with the source library rather than the target library, but if you didn't have write access to the source library that would result in a sync error. (I also added a check to make sure it can never save a relation to a read-only library.)

    The fix will be in 4.0.13, but you can install the 4.0 branch dev build now if you want to test it.
  • Outstanding service guys....thanks so much for your work.
Sign In or Register to comment.