- Annotations are displayed in itemTree under their file attachments
on a third level. The annotation spans the entire row.
- The title is constructed on the go. When possible, it
includes annotation quote and comment as pseudo-columns
of the row. The comment occupies about twice as much space as
the quote. Otherwise, (if there is no quote) only the annotation
comment
is included as the "title" part of the row
- Non-CJK segments of the quote part of the annotation row are
italicized. CJK segments are left as is. If CJK segments are present,
there is more padding between quote and comment parts.
- Search matches the actual attachment instead of its parent file.
- Can create child notes from annotations of the same item or
standalone notes from annotations across different items from
the context menu or the header button.
- When an annotation (or multiple annotations) are selected, the
annotationItemPane component is displayed where annotations are
grouped by their top-level item. Annotations are displayed fully,
without having their content cut off.
- Special treatment for annotations to always prompt
to erase the item regardless of what collectionTree row
is selected (e.g., if a collection is selected, we
still want one to be able to delete the annotation).
This only applies if all selected items are annotations.
If multiple items are selected, some annotations and
some not, do nothing. This is until the trash is
ready. In the future, we may send annotations to trash
- strip all HTML tags from annotation for now, until the logic to
properly render annotation markup is copied over from the reader
(applies to both annotation-row component and the annotation
item rendered in the itemTree)
- Added a generalized "expandToItem" function to itemTree to
expand all ancestors of a given item, similar to "expandToCollection"
from collectionTree
- add annotation conditions to advanced search
- show [Image not available] if no annotation file for ink or image
annotations
- only keep annotation-specific context menu options when some
annotations are selected in itemTree
- enable Quick Copy of annotations from itemTree via drag-drop,
shortcut key, or Edit → Copy Annotation
- Minor refactoring of Zotero.Annotation.toJSON() to pull out async code
that handles ink and image annotations, so that
Zotero.Annotation.toJSONsync() for highlight, underline, and note
annotations does not have to be awaited. Since ink and image
annotation don't seem to work for drag-drop Quick Copy, they are just
skipped for now.
A browser window was no longer actually needed for charset detection
(on macOS, at least, and hopefully elsewhere) because we switched to a
HiddenFrame-based hidden browser. Remaining uses now call
`loadZoteroWindow()`.
Fix the glitch where having anyField search condition
along with any other condition would return an empty
result set if joinMode="any".
This would happen due to a conflict between conditions
caused by wrapping "anyField" condition set into a quickSearch
block, which enforces "AND" operator between conditions.
Fixes: #4830
- revert change from 2401a34031
that only loads un-trashed collections in _loadCollections.
If an item only belongs to deleted collections, item._loaded.collections = true
from _loadCollections will never run, so an exception
will be thrown in item.toJSON() when syncing happens.
Instead, to address the problem of item.getCollections()
having stale data #4307, add 'includeTrashed' parameter to
item.getCollections() based on which item._collections
will be filtered. Fixes: #4346
- revert earlier, no more necessary, changes from a532cfb475
to not alter item._collections cache when collections are being trashed or restored.
Collection is removed from item._collections only when it is permanently
erased.
- removed unnecessary test checking for consistent item._collections
value before and after reload, since item._collections is no longer
modified
- fix encountered bug where a trashed child collection is not
unloaded if a parent collection is erased without being trashed first.
- tweaked Zotero.Search sql construction to count items
that only belong to trashed collections into 'unfiled'. Fixes: #4347
---------
Co-authored-by: Dan Stillman
When a collection or a saved search is deleted, it appears in
trash among other trashed items. From there, it can be restored
or permanently deleted.
Items of trashed collections are not affected my the trashing/permanent
deletion of a collection and need to be deleted separately like before.
Subcollections of a trashed collection do not appear in the trash and
are restored or permanently deleted with the top-most trashed parent.
Prevents bug in zotero-citation plugin (at least on macOS) from creating
a search that breaks syncing
We were already checking for a missing name in `saveTx()`, but the
plugin is saving the same search twice in rapid succession, the second
time without a name, and the second attempt clears the search object's
name value after the first save's `_initSave()` check and before its SQL
write. The second save fails, but the first save goes through without a
name, resulting in a sync error.
https://forums.zotero.org/discussion/104274/id-1702002152-cannot-synchttps://github.com/MuiseDestiny/zotero-citation/issues/31
Expose annotation tags in tag selector and match parent attachments when
filtering/searching
This also fixes searching for annotation text or comments when using
Everything quick search.
This is temporary until we display annotations in the items list
directly.
This lays the groundwork for moving collections and searches to the
trash instead of deleting them outright. We're not doing that yet, so
the `deleted` property will never be set (except for items), but this
will allow clients from this point forward to sync collections and
searches with that property for when it's used in the future. For now,
such objects will just be hidden from the collections pane as if they
had been deleted.
This changes the way item types, item fields, creator types, and CSL
mappings are defined and handled, in preparation for updated types and
fields.
Instead of being predefined in SQL files or code, type/field info is
read from a bundled JSON file shared with other parts of the Zotero
ecosystem [1], referred to as the "global schema". Updates to the
bundled schema file are automatically applied to the database at first
run, allowing changes to be made consistently across apps.
When syncing, invalid JSON properties are now rejected instead of being
ignored and processed later, which will allow for schema changes to be
made without causing problems in existing clients. We considered many
alternative approaches, but this approach is by far the simplest,
safest, and most transparent to the user.
For now, there are no actual changes to types and fields, since we'll
first need to do a sync cut-off for earlier versions that don't reject
invalid properties.
For third-party code, the main change is that type and field IDs should
no longer be hard-coded, since they may not be consistent in new
installs. For example, code should use `Zotero.ItemTypes.getID('note')`
instead of hard-coding `1`.
[1] https://github.com/zotero/zotero-schema
- Fix incorrect results for ANY search with multiple "Attachment
Content" conditions and no other conditions
- Dramatically speed up single-word searches by avoiding unnecessary
text scans (which probably addresses #1595)
- Clean up code
When adding many search conditions (e.g., when matching many items with the
`key` condition), the query can fail due to either the bound parameter limit or
the expression tree size limit.
To avoid this, add support for an 'inlineFilter' property on search conditions
when using the 'is' or 'isNot' operator. 'inlineFilter' is a function that
returns a quoted value suitable for direct embedding in the SQL statement, or
false if not valid. Multiple consecutive conditions for the same 'inlineFilter'
field are combined into an `IN (x, y, z)` condition.
With icons to identify collections and searches
Also:
- `savedSearch` search condition in general
- Clean up some search window code
- Reorganize search tests
While trying to get translation and citing working with asynchronously
generated data, we realized that drag-and-drop support was going to
be...problematic. Firefox only supports synchronous methods for
providing drag data (unlike, it seems, the DataTransferItem interface
supported by Chrome), which means that we'd need to preload all relevant
data on item selection (bounded by export.quickCopy.dragLimit) and keep
the translate/cite methods synchronous (or maintain two separate
versions).
What we're trying instead is doing what I said in #518 we weren't going
to do: loading most object data on startup and leaving many more
functions synchronous. Essentially, this takes the various load*()
methods described in #518, moves them to startup, and makes them operate
on entire libraries rather than individual objects.
The obvious downside here (other than undoing much of the work of the
last many months) is that it increases startup time, potentially quite a
lot for larger libraries. On my laptop, with a 3,000-item library, this
adds about 3 seconds to startup time. I haven't yet tested with larger
libraries. But I'm hoping that we can optimize this further to reduce
that delay. Among other things, this is loading data for all libraries,
when it should be able to load data only for the library being viewed.
But this is also fundamentally just doing some SELECT queries and
storing the results, so it really shouldn't need to be that slow (though
performance may be bounded a bit here by XPCOM overhead).
If we can make this fast enough, it means that third-party plugins
should be able to remain much closer to their current designs. (Some
things, including saving, will still need to be made asynchronous.)
