When non-conflicting changes were automatically merged, the local object
would be correctly marked as unsynced, but the merged object rather than
the remote object would be saved to the sync cache. When the object was
then uploaded, it matched the cache version exactly, so an empty patch
object (other than an unchanged dateModified, which is always included)
would be uploaded and the local change wouldn't make it to the server.
The empty patch would result in an 'unchanged' response, which would
cause the empty patch object to be saved to the sync cache (which is a
bug that I'll fix separately). If the local object was modified again,
the patch would include all fields (since the cache object was empty)
and the local change would be uploaded, but there could also be
unnecessary conflicts due to it looking like all local fields had been
modified.
This patch causes the remote object to be saved to the sync cache
instead, so the local change looks like a local edit and is correctly
uploaded.
Don't include linked-object or replaced-item relations. Previously, if
you duplicated an item, modified it to represent a different source, and
dragged it to another library where you had already copied the original
item, the new item wouldn't be transferred.
https://forums.zotero.org/discussion/comment/353246/#Comment_353246
Apparently we implemented this 5 years ago in #873 and then broke it
(with the move to React, I think) without ever announcing it as a new
feature in Zotero 5? Anyway, this restores it, using Cmd on macOS (the
same as for moving vs copying items, or files in Finder).
Since at least 2009, for reasons unclear, we've used `dialog=no` when
`instantApply` is true (macOS/Linux) and `modal` (with implicit
`dialog=yes`) when false (Windows). `dialog=no` doesn't seem to have an
effect on macOS, and `modal` doesn't seem to have an effect on Windows
(at least with `openDialog()`), but on Linux `dialog=no` allows the
dialog to be resized, which it shouldn't be, and causes problems with a
tiling window manager. This change switches to the implicit `dialog=yes`
on all platforms. (On Linux, this also centers the dialog on the screen,
keeps it in front of other windows, and does a weird opening animation.)
https://forums.zotero.org/discussion/82050/zotero-preferences-window-issue-with-tiling-window-managers
This should dramatically improve import speed for large imports by
delaying UI updates until the import finishes.
Additional Zotero.Attachments methods now support `saveOptions` to
support `notifierQueue`.
'podcast' is now the first mapped type for 'broadcast', per
https://forums.zotero.org/discussion/comment/351113/#Comment_351113, so
we need to check for fields not available in 'podcast'. 'radioBroadcast'
will be converted to 'tvBroadcast' on re-import, but that was the case
before.
- When changing type based on 'type:' line, move existing fields that
are no longer valid to Extra
- Remove 'type:' line with CSL type if the item's existing type is one
of the types mapped to it
getAllAddons() waits for extensions to be initialized, so the code in
Prefs::loadExtensionDefaults() to delete an extensions.json with an
AppTranslocation path should be sufficient, and it shouldn't be
necessary to check for it after showing the AppTranslocation startup
error.
If a Mac user first starts Zotero from the disk image, Zotero
shows an error telling them to install the app in Applications, but the
integration plugins will have already be registered in extensions.json
with paths to the temporary AppTranslocation directory. This meant that
the next time the user restarted their computer (or sooner), the AppTranslocation
directory would be cleared and the integration plugins would no longer
be loaded.
This deletes extensions.json if it contains an AppTranslocation path for
an extension when the app is started from the disk image, which should
prevent this going forward. For existing users experiencing this, it
also checks installed extensions at startup for AppTranslocation paths
and deletes extensions.json if any appear.
This shouldn't actually be used currently, since only notes and
attachments lack creators and it shouldn't be possible to change regular
items into notes or attachments.
