Mailing list mode now includes the 'no echo' option: to only receive emails of posts not created
by you. If you reply to an email thread in mailing list mode, your reply will not then be echoed
back to you in a duplicate email by the system.
Adds a "Step 0" to the wizard if the site has no admin accounts where
the user is prompted to finish setting up their admin account from the
list of acceptable email addresses.
Once confirmed, the wizard begins.
previously we supported blanket read and write for user API, this
change amends it so we can define more limited scopes. A scope only
covers a few routes. You can not grant access to part of the site and
leave a large amount of the information hidden to API consumer.
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
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.