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
This reduces the number of scans that the db has to do in the query
to fetch orphan uploads. Futheremore, we were not batching our
records which bloats memory.
Also changes behaviour of real to not return anonymous users.
This means user counts will no longer include them, and the
mailing list system will ignore them even if they somehow end up
with the feature turned on.
If force_avatar_update is passed in sso attributes it errors on
force_avatar_update.to_i. The SingleSignOn class forces avatar_force_update
to a boolean, so it should be treated as such.
If a user has a current avatar, and sso_overrides_avatar is true, but no avatar_url is
passed in the sso attributes, the current code errors, as it tries to parse a nil
as a URL. It seems to me valid that a third party system may not pass an avatar_url in
some cases (e.g. avatars may not be mandatory, so not all users may have them)
This might warrant a discussion about what should happen in this case; maybe the current
avatar in discourse should be removed? This branch merely stops the login process erroring.
Due to what seems to be a bug in ActiveRecord, the distinct: true option
is not recognized on counts with string column names. This commit fixes
that by moving the DISTINCT into the count string.
For robustness, the integration spec for IncomingLinksReport was
rewritten to be an actual integration spec, running the actual interface
on actual fake data.
FIX: history revision can now properly be hidden
FIX: PostRevision serializer is now entirely dynamic to properly handle
hidden revisions
FIX: default history modal to "side by side" view on mobile
FIX: properly hiden which revision has been hidden
UX: inline category/user/wiki/post_type changes with the revision
details
FEATURE: new '/posts/:post_id/revisions/latest' endpoint to retrieve
latest revision
UX: do not show the hide/show revision button on mobile (no room for
them)
UX: remove CSS transitions on the buttons in the history modal
FIX: PostRevisor now handles all the changes that might create new
revisions
FIX: PostRevision.ensure_consistency! was wrong due to off by 1
mistake...
refactored topic's callbacks for better readability
extracted 'PostRevisionGuardian'
Changed internals so trust levels are referred to with
TrustLevel[1], TrustLevel[2] etc.
This gives us much better flexibility naming trust levels, these names
are meant to be controlled by various communities.