Well this was a wild one to debug.
Creator fields were only initialized for autocomplete due to a series of
>10-year-old bugs:
1) In `showEditor()`, `Zotero.ItemFields.isAutocompleteField(fieldName)`
was called for creator fields, which would pass, e.g.,
`creator-0-lastName`.
2) In `isAutocompleteField()`, `ItemFields.getName()` would normalize
`creator-0-lastName` to `false`, since it's not a valid field.
3) `isAutocompleteField()` listed `place` as a base field despite its
not having any mapped fields, so when `getTypeFieldsFromBase()` was
called on it, the return value would be `false`, which would be added
to the list of autocomplete fields, which would mean that the
normalized field of `false` from `creator-0-lastName` would match,
which would mean that `isAutocompleteField('creator-0-lastName')`
would always return true...as long as `place` never gained a mapped
field.
Except `isAutocompleteField()` wasn't supposed to be the test for
initializing autocomplete for creator fields anyway -- `fieldName ==
'creator'` was. But `fieldName` is something like `creator-0-lastName`,
not `creator`, which meant that that test always failed, which meant
that if `place` did gain a mapped field, both tests would fail, which
would cause the creator field not to be initialized for autocomplete,
which would cause it to break as soon as you started to type into it.
This fixes that.
Using the Headers class from the Fetch API.
Before, the added test would fail: `_requestInternal()`, not finding a header
named `Content-Type` (case sensitive), would set it to
`application/x-www-form-urlencoded`. XMLHttpRequest, upon being given both
`content-type`: `application/json`) and `Content-Type`:
`application/x-www-form-urlencoded`, would helpfully merge the two, producing
`content-type`: `application/json, application/x-www-form-urlencoded`. That's
obviously not the correct behavior.
Limited to a hard-coded list
Initially limited to `extensions.zotero.import.mendeleyUseOAuth`,
to switch the Mendeley importer from direct login to OAuth
- Show "More information" link next to relink option
- Automatically check relink option when coming from integration prompt
- Change done message to "[x] items were relinked" instead of "0 items
were imported"
New option only appears if importer version is < 1 or not present.
It will:
* Skip fetching collections and attachments
* Skip any new items
* Update relations on existing items
* Importer will now ask user for a login and password via form and will perform sign-in directly
using credentials rather than oauth
* Signing in this way enables importer to obtain desktop document ID which is now stored for each
item
* It's possible to switch back to the old method (ouath) by setting `import.mendeleyUseOAuth` pref
to `true`.
* New option to only import new items. This options only appears if database contains previously
imported items.
* Importer will now update mendeleyDB:documentUUID on existing items to match value used in Mendeley
Desktop if available
* Importer will no longer create collections when no new items are imported
* Importer will only report number of new items imported on re-import
* Importer will now preserve dateAdded on re-import
Co-authored-by: Dan Stillman <dstillman@zotero.org>
Previously cookies only got attached on the initial request but not on
any redirect and subsequent request. This may have been the cause for
many reports of import failures behind proxies in the past.
Technically this code has been wrong for a long time, but it only
manifest now. It seems that the equivalent code in translate module
was fixed when that code was extracted into a separate repo
In this case, Note Markdown wouldn't be preloaded, but it's always used
for copying from the note editor, and since the note editor uses
`noWait`, this would result in "Code promise is not resolved in noWait
mode".
Zotero.Translators.reinit() didn't reinit Quick Copy, so if an export
translator was selected it wouldn't be preloaded again and dragging
would fail with "Code promise is not resolved in noWait mode".
Find Available PDF has its own domain-based retry logic that predated
automatic 5xx retries in Zotero.HTTP, so disable the latter and fix some
bugs in the former.
Fixes#2700
Also:
- Hide format options until translators are loaded (since otherwise
the checkboxes don't have labels and the layout is messed up)
- Remove unnecessary "zotero-" prefix from the new elements
The default JSON pref value used spaces, but changing the drop-down
resulted in a version without spaces, so simply changing the default to
include the new link options wouldn't change all existing installs and
the "Include App Links" checkbox wouldn't show as enabled for Markdown.
This adds a pref migration step to reset the pref to the new default if
it's set to Markdown + Rich Text, regardless of whitespace differences.
People are confused by "Zotero Connector Server is Available". I'm not
sure if this will be any better, but not mentioning the connector might
help -- that seems to be part of the problem.
We could display a longer message with a link to
https://www.zotero.org/support/kb/connector_zotero_unavailable, but this
is the /ping page that gets hit constantly, so it seems like we should
keep it short (though probably it doesn't make a difference).
