feat(plugins): let a plugin display its own result set in the message list - #955
Open
aspuru wants to merge 1 commit into
Open
feat(plugins): let a plugin display its own result set in the message list#955aspuru wants to merge 1 commit into
aspuru wants to merge 1 commit into
Conversation
… list Adds `api.search.showMessages(ids, label)`. A plugin that does its own retrieval can hand the host a list of email ids and a label, and the host renders exactly those messages in the message list, with the label shown where a search term normally appears. Today a plugin can read messages and draw its own UI, but the message list is closed to it: category tabs only filter into the fixed buckets, and `api.ui` has no navigation. The nearest workaround is emitting a search query for the user to run, which only works when the result set happens to be expressible as a query. Two clearing rules, both covered by tests: - Typing a search replaces a plugin's list, so a user's own search always wins. - Changing folder clears a plugin's list but NOT a user's search. A search is deliberately kept across folders upstream and scoped by `searchMailboxId`; a plugin-supplied set has no equivalent scope, so it is dropped rather than silently reinterpreted. Closes bulwarkmail#954
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements
api.search.showMessages(ids, label)as described in #954: a plugin that does its ownretrieval can hand the host a set of email ids and a label, and the host renders exactly those
messages in the message list.
What it does
The list shows those messages and the label appears where a search term normally would, so the
user can see why the list looks that way and clear it like any other search.
Clearing rules
Both are covered by tests, and the second one is the non-obvious one:
across folders and scoped by
searchMailboxId. A plugin-supplied set has no equivalent scope, socarrying it into another folder would silently reinterpret it — it is dropped instead.
Scope and safety
ui:message-listpermission, declared alongside the existing capabilities.cannot surface a message the user could not already open. Strictly weaker than
tabs.categorize,which writes keywords.
keeps one call from pulling a whole mailbox through
Email/get.Tests
stores/__tests__/email-store-show-messages.test.ts— 10 tests covering theisPluginListlifecycle and both clearing rules. Passing against this branch:
eslintreports no new problems; the warnings it emits on this tree are pre-existing.Notes
Based on
1.9.2. Happy to change the name, the signature, or the clearing semantics — the shapehere is what fell out of using it rather than a strong opinion, and I'd rather match your
preference than land it as-is.