This avoids redundant field migration on other devices if it has already
run on one. Conflict resolution should automatically ignore identical
changes, so it's not the end of the world if it runs in multiple places,
but we might as well avoid it if we can.
Creators shouldn't be extracted if creators of the same type already
exist on the item, to follow citeproc-js behavior, but the code to do
that was broken.
When a Zotero plugin is disabled, user-modified preferences can be inadvertently reset to their default values. This occurs under specific conditions where a parent preference has not been user-modified, but a child preference within that branch *has* been modified.
The root cause lies in the `Zotero.Plugins.clearDefaultPrefs` function. For preferences that do not have a user-set value (`!branch.prefHasUserValue(pref)`), it incorrectly calls `Services.prefs.getDefaultBranch('').deleteBranch(pref)`. While intended to clear unmodified defaults, `deleteBranch(pref)` operates on the *entire preference branch* starting with `pref`, inadvertently removing any user-modified sub-preferences as well.
This commit changes the problematic line from `branch.deleteBranch(pref)` to `branch.clearUserPref(pref)`. `clearUserPref(pref)` correctly removes only the user-set value for the *specific* preference `pref`, leaving default values and any user-modified sub-preferences intact. This ensures that only truly unmodified default preferences are cleared, preserving user data for related sub-preferences.
This fix prevents unintended loss of user settings when plugins are disabled.
Fix createParentDialog hanging when opened during
quicksearch or in saved search. After a parent item
is added, itemTree is being refreshed. If _refreshPromise
is resolved after a timeout, it will not complete until the
modal dialog is closed. Instead, resolve _refreshPromise
after Zotero.Promise.delay, which uses the XPCOM global
timer unaffected by modals.
Fixes: #3026
When drag-dropping items into a collection in another library,
perform the addition to collection in the same transaction
as creating a new item in the target library.
When the librariesCollectionsBox refreshes on the `modify` event
when a newly created group item is linked to the selected item,
it re-loads the data of the linked item via item.loadAllData().
This could happen after the item is added to the collection
but before this change is saved. In that case, item._changed.collections
would be cleared, and when the item is saved, there would be
no changes to collections to save.
Fixes: #5539
Also, cleanup leftover unused logic of restoring linked item
from trash on drop that was removed in 2dd16b44d6
And require checkbox or text challenge depending on the severity of the
action
Includes replacement for Set.prototype.difference() for Fx115
---------
Co-authored-by: Dan Stillman <dstillman@zotero.org>
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
