Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saved Search UI is broken #2180

BjarniRunar opened this issue Nov 28, 2018 · 1 comment


Copy link

commented Nov 28, 2018

When creating a Saved Search, sometimes the modal doesn't close, even if the search was successfully created. Why, oh why?

This happens at least when replacing an existing search, but may also happen in other cases.

@BjarniRunar BjarniRunar added this to the 1.0 Release milestone Nov 28, 2018


This comment has been minimized.

Copy link

commented Jul 29, 2019

(2019-07-31 - Edited after input from @BjarniRunar - thanks Bjarni.)

A Saved Search is created by entering search terms in the search bar at the top of the search results screen, clicking the button, then clicking the *Save button (in the bar immediately below the search bar) and using the modal that pops up.

This is a way of creating a "filter" as documented by CLI help filter. This should

  • create a tag,
  • tag all current matches, and
  • tag all future matches.

This is different from enabling automatic Bayes classification - the explicit search terms specified in the search bar should be used.

The CLI filter command is believed to work.

Results of testing on commit 6e61761 dated 2019-07-20 on Debian Jessie with Firefox:

Sometimes the modal doesn't close (see above)

Testing showed that the modal never closes when the Save Search button on the modal is clicked, but only when the X (close) button at the top right of the modal is clicked. If the Save Search button is clicked multiple times, then multiple tags are created with the same name - not good!

The *Save button is not shown if the first search term in the search bar is a mailbox.

  • Searching for date:2019 in:inbox results in the *Save button being displayed.
  • Searching for in:inbox date:2019 (the same terms in a different order) results in the *Edit button being displayed. If the *Edit button is then clicked, the modal that pops up is set up to edit the Inbox tag. Looks dangerous!

A search term like in:tagname should not be allowed in a filter since that would lead to one filter referring to another filter with many possible complications. That is the reasoning behind displaying *Edit instead of *Save. But the order of terms clearly should not make a difference. Reasonable behaviour of the *Edit and *Save buttons should be specified and implemented. Note that a search, using the search bar, like in:freecycle in:inbox works and makes sense, but we can't allow that to be a saved search, so *Save should not be displayed. But if *Edit is displayed, which of the tags should be made available for editing? Perhaps it is better to display neither button if there is more than one search term and one of the search terms is a tag.

Keywords like saved-search-8 are displayed to the user but their significance is not stated.
If a tag is edited, these are seen in the in the Edit-Technical Settings-Keyword field. If a tag for a saved search is clicked in the sidebar, this type of keyword appear in the search bar e.g. in:saved-search-1. It would be better if the original search terms were displayed. Failing that, the tag name that was assigned by the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.