Prior:
Entering `test after:5` and then removing the 5 via the search text field would result in the UI not updating
After:
UI updates after half a second
Removing it from the UI, removes it from the search field immediately.
Change the regex to detect filter words. This now matches what happens in search.rb, which gives a lot more flexibility (such as iterating over multiple `in:` terms)
Return [] when searchTerm is empty
Move .trim() to this.set('searchTerm', searchTerm) so it doesn't run twice (which was very obvious when watching the search term field)
More refactoring to make this a bit less complex
Update code based on review comments
FEATURE: Add common `in:` options
Properly support Categories so it updates the search box correctly
Use category id, as it is more consistent with search results than using the slugs, especially for parent/subcategory
Added Status
Improve AutoComplete so it can receive updates
Added the ability for AutoComplete to receive updates to badge-selector and group-selector
Respect null, which is set via web-hooks
Support both # and category: for category detection.
Only update the searchedTerms if they differ from its current value (this helps the Category Selector receive updates)
Opt in receive updates (#3)
* Make the selectors opt-in for receiving updates
* Opt-in to receive updates
* Fix category detection for search-advanced-options
Fix eslint error
Update user-selector so it can receive updates live too
Make the canReceiveUpdates check validate against 'true'
Converted to use template literals
Refactor the regex involved with this feature
Split apart the init to make it a bit more manageable/testable
Switch the category selector to category-chooser, so it is a dropdown of categories instead of auto-complete
Reduce RegEx to make this happier with unicode languages and reduce some of the complexity
Removed the `post "t"` route from the routes file because the
`topics#create` action doesn't exist in the topics controller. New
topics are created in the posts controller.
If a site is configured for GitHub logins, _**and**_ has an email domain
whitelist, it's possible to get in a state where a new user is locked to
a non-whitelist email (their GitHub primary) even though they have an
alternate email that's on the whitelist. In all cases, the GitHub
primary email is attempted first so that previously existing behavior
will be the default.
- Add whitelist/blacklist support to GithubAuthenticator (via
EmailValidator)
- Add multiple email support GithubAuthenticator
- Add test specs for GithubAuthenticator
- Add authenticator-agnostic "none of your email addresses are allowed"
error message.
cpradio
Arpit Jalan
Jeff Atwood
Sam
Neil Lalonde
Blake Erickson
Vibol Hou
Rafael dos Santos Silva
Robin Ward
Jared Reisinger