We were skipping updating of `clientDateModified` in order to prevent an
attachment item upload, but that hasn't been used since Zotero 4. This
might mean that, in some rare situations (e.g., a filename that needed to
be shortened due to filesystem path length?), people in read-only or
non-files-editable groups may have ended up triggering access errors and
needing to reset local data after a file download.
Now, we properly skip marking the attachment item as unsynced.
We've always done this, but it's no longer necessary:
- If a file exists locally when a remote filename change comes in, we
now rename the local file.
- If a file doesn't exist locally and it's a single file, we save the
file with the new filename on the next file download.
- If a file doesn't exist locally and it's an old multi-file snapshot,
we now try to find the primary HTML file and rename it.
If a file was renamed remotely and a new copy wasn't uploaded for some
reason, the ZIP wouldn't contain the new filename. We already renamed a
single file within the ZIP to match the new filename, but now we also
rename a single HTML file in old multi-file snapshot ZIPs. If there are
multiple HTML files for some reason (old-style ZIP with iframes?), we
let the user fix it.
And then we can stop reuploading files after renames.
Previously, the local file wasn't renamed, so it would become unlinked.
Since we currently force reuploading/reregistering of files when they're
renamed, opening the attachment would then redownload the modified
remote file, but there's no need for the file to become unlinked in the
first place.
restoreProcessorState() breaks locale-specific punctuation (and is
deprecated).
rebuildProcessorState() is enough if we're passing an empty citation
list; if we're reinitializing with a new non-empty list, call
updateItems() first.
Also:
- Add tests for this issue and for potential regressions in disambiguation handling
When resizing the window in list mode to match the height
of the content, account for the difference between
outerHeight and innerHeight of the window on Linux.
outerHeight > innerHeight (perhaps Linux includes chrome,
borders, etc. in its outerHeight), so we have to add their difference
to the desired height for resizing. Otherwise, the visible
dialog ends up receiving only some of the desired height and
the last row is cut off.
Also, ensure that in tests, we wait for searching triggered by
switching dialog mode to finish before running the next search.
Fixes: zotero#5502
By using getSelectedItems() instead of getSelectedObjects(). The code
below all assumes that `items` contains items, and we handle general
(item or collection) options above, so this seems more correct.
And fix duplicate var.
Fix ghost relations to erased items reappearing after
sync. The dataserver ensures that related relations are
bidirectional. If a related item is erased, syncing
would first upload the update to the remaining related item
(where the relation is removed), followed by the deletions.
While handling update upload, the dataserver would return
the old, should-be-removed, "dc:relation" entry for that item
because it does not know that the other item is erased.
To handle this, swap the order of operations during sync:
upload deletion first and then upload updates after.
Then, when the dataserver handles the update of the non-erased item,
there is no related item to enforce bidirectional relations to.
Fixes: #5481
Fixes tabbing out of Scaffold's abstract box causing the test item to be
added to the user's library.
And use same format as itemPaneHeader.js in abstractBox.js.
Hopefully a better fix for #4981, which wasn't working properly on at
least some Linux systems because the variables were getting restored
before the subprocess launched. This delays a (debounced) second, to
give the subprocess time to start, and then automatically restores the
variables.
An explicit restart via app code also immediately restores the
variables, since restarts on Linux inherent the environment and don't
use our startup script. (An upgrade restart could still happen when the
variables were cleared, but you'd have to be extremely unlucky --
launching URLs or files while also performing a manual restart the same
second.)
