Zotero.File.move() now forces `overwrite` if the old and new filenames
differ only by case, since otherwise on a case-insensitive filesystem
OS.File.move() does an existence check and thinks that the target file
exists.
Prior to fdfa8052d1, it was possible to create an item in a feed
library using Add Item by Identifier. If you did that, and then copied
it to a collection in your personal library, it would somehow end up
with an owl:sameAs relation to a `/users/local` URI (probably because
the URI functions don't work properly on a feed library).
This will clean up such relations in a schema update.
Most importantly, don't allow Add Item by Identifier to create an item
in a feed library...
The other buttons didn't do anything but still showed an effect on
mousedown, which this prevents.
If repo.zotero.org returned a 500 during Zotero startup, translators and
styles wouldn't be initialized until a 200 was returned, and various
things that depended on translators or styles wouldn't work in the
meantime. Now a single retry is made after 5 seconds, and if that fails
the promise is resolved regardless.
Regression from dc60e5f840, which added automatic 5xx retrying to
Zotero.HTTP.request()
Previously, if an object was uploaded but the API returned 'unchanged',
the uploaded data would be written to the sync cache, which, given that
most requests are patch requests, could result in an empty or mostly
empty object being saved to the sync cache. That would cause the next
sync to treat most/all local fields as changed and either upload them
unnecessarily or trigger a conflict instead of merging changes
automatically.
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.
