Since the search filter and sort menus have moved into the header, hiding it
after the first page means that users can only change the sort/filtering options
on page 1.
The js that controls the showing/hiding of the menus expect each dropdown
element to be the only instance amongst its siblings. In other words, each
dropdown button and list must be wrapped in a container element for it to work
correctly.
Additionally, this moves the filter menus to the right side of the header for
better visibility.
Adds new render classes for link and subreddit search results, a new stylesheet for
search, and new mako templates for the search result classes and the search listing.
Conflicts:
r2/r2/controllers/front.py
Conflicts:
r2/r2/controllers/front.py
r2/r2/models/listing.py
r2/r2/public/static/css/reddit.less
Our throttling on the share dialog has been a bit odd. We didn't allow you to
share more than once every `RL_RESET_MINUTES`, **unless** you have at least
`MIN_RATE_LIMIT_KARMA` in the subreddit you're sharing from. Why was this tied
to the subreddit? Who knows!
Rather than having a draconian limit and exempting some users from it, the rate
limits on sharing should now be at a reasonable level for everyone (and
configurable as we go with `RL_SHARE_AVG_PER_SEC`). In addition, we're now
using the fairly new ratelimit library, which allows for burstable usage, so a
user who wants to share several things in a row but then goes back to normal
browsing is much less likely to get throttled.
This commit contains a number of improvements for the message sent to
users when they are banned from a subreddit:
* Message is different for temporary bans, and includes duration
* Includes information about being able to reply to the message, and the
fact that circumventing a ban is considered a site rules violation
* Nicer formatting by blockquoting the note from the moderators
* Fixes the "phantom modmail notification" when someone is banned
* Refactored into separate function, which cleans up notify_user_added
This change was intended primarily to address an issue related to
duplicate username mentions - each individual mention was being counted
towards the per-comment limit, instead of it only counting mentions of
different users. So mentioning the same user 4 times in a comment would
cause butler to bail out instead of sending a mention to that user.
So this makes it so that extract_user_mentions now returns the
mentioned usernames as a set instead of a list, and also removes the
support inside the function itself for only returning up to a maximum
number of mentions. It is now up to the caller to worry about handling
the number of mentions returned (which actually simplifies things almost
everywhere this is currently being used).
This was mostly already covered by the check in should_check_item that
makes AutoMod skip over items that have been removed by moderators, but
it didn't cover rules that triggered on a comment and used that to
approve the parent submission. Rules using that sort of check/action
would cause parent submissions that had previously been removed by
moderators to be re-approved, which isn't desirable.
The variable that holds the result of attempting to match the search
check was not being reset for each individual check, so if a check was
skipped due to its fields being discarded, it would keep the same value
it had from a previous check.
In practice, this means that a check like this will not match on a link
submission to baddomain.com:
url+body: "baddomain.com"
~body: "I'm an exception"
The match from the url check would still be present after the ~body
check was skipped, so this would end up causing the rule to be
considered unsatisfied, since the ~body check would seem to have matched
successfully.
