- 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.
81739c7a66 prevented new windows from working after a restart error,
and full-text tests (and possibly others) create attachments quickly in
a way that was causing init callbacks to receive a TinyMCE editor with
missing functions (possibly because they were already removed?). This
just ignores those errors, which isn't a great solution, but it probably
won't happen in real use, so let's see if it works.
It shouldn't be possible to nest two collections inside each other, but
if it happens, fix it in the integrity check.
Also detect it from CollectionTreeView::expandToCollection() (used when
showing the collections containing an item) and crash Zotero with a flag
to run an integrity check after restart. Previously, this would result
in an infinite loop.
This may be the cause of some of the collection disappearances people
have reported. If parentCollectionID never leads to a null, the
collection won't appear anywhere in the tree.
TODO:
- Figure out how this is happening
- Detect and fix it automatically for people it's happened to
If you'd never set a Quick Copy locale, the option would show as using
the current locale, but Quick Copy itself would use the last locale from
"Create Bibliography from Items". That was a side effect of behavior we
put in place in 2015 so that documents created before 4.0.27 that relied
on the removed bibliographyLocale pref would continue using the migrated
locale, but now that we've had an explicit locale option for years in
the document preferences I think we can stop doing that.
This prevents a second copy of Zotero from being launched if you're
running the Zotero beta and click on a word processor plugin button
while a dialog is already open.
Previously, files updated remotely wouldn't be downloaded in "as needed"
mode if a copy of the file already existed locally and could only be
re-downloaded by deleting the file via Show File.
This causes remotely modified files that exist locally to be downloaded
at sync time, even in "as needed" mode, by marking them as
"force_download". While this might not be ideal for people who use "as
needed" to limit data transfer, it's better for people who use it simply
to limit local storage, and ending up with an outdated file while
offline seems worse than a little bit of extra data transfer.
In the future, we'll likely also provide ways to explicitly download and
remove files, so keeping chosen files in sync makes sense.
Files modified remotely before this change (which were marked as
"to_download" instead of "force_download") won't be downloaded as sync
time in "as needed" mode, but they'll now be re-downloaded on open.
Fixes#1322
- Use full-text cache file from syncing if available when reindexing via
info pane or Rebuild Index → Index Unindexed Items. Only discard it for
full index rebuild. This allows Index Unindexed Items to be used to
force immediate processing of queued content from syncing and avoids
unnecessary syncing back of identical content. Previously, the cache
file was used for a manual index only when the local file didn't exist.
- When rebuilding index, don't clear indexed items with missing local
file that are missing stats due to a pre-411180ef bug.
- indexItems() now takes an 'options' object as its second parameter
- Minor code cleanup
- Don't clear item's index stats (and show "Unknown") when an item is
reindexed remotely and the content matches the local content
- Always update an item's state and its stats in the same query, to
avoid incorrect feedback immediately after indexing
- Clean up `setItemContent()` tests
