Removes the following awards / fields on User:
- flairlock
- progressivestack
- bird
- longpost (pizzashill)
- marseyawarded
- rehab
- deflector
- mute
- unmutable
- eye (All-Seeing Eye)
- alt (Alt-Seeing Eye)
Primarily motivated by starting to remove some un-Mottelike cruft
from core commenting/posting routes. Cleared out other inapplicable
awards while in the process.
PR #374 removed `@auth_required` from a number of routes and changed
those which used their `v` parameters to `v=None` and removed the `v`
parameter from those which didn't internally use it. 1841134b47
PR #392 re-added `@auth_desired` to those routes to ensure the
templates rendered with awareness of the current logged-in user
(matters for search, header bar, etc). 9f042c1aeb
However, 500 errors occurred on /random_post, /random_user, /id/<uid>,
and /u/<username>. Those were the four which had their `v` parameter
removed entirely. This has been re-added, which fixes the bug.
The way to understand auth_required vs auth_desired is that they are
nearly identical, with the sole difference than auth_required
checks if v is None and aborts with 401 if so. This means that
auth_desired routes must handle the v=None case. They are the same in
that they always try to give a `v` kwarg to the decorated function,
which was the root cause of those four routes erroring.
Recommended style: the vast majority of routes which return a rendered
template should be auth_desired, because the top-level templates often
draw extensively from `v` state even when the route handler does not.
When a route is either auth_desired or auth_required, it should have a
`v` parameter, which we typically give as the first positional
parameter.
This commit adds the @auth_desired decorator to
routes that previous had the @auth_required decorator,
but had it removed in #374. This should cause
the user to remain logged in on these routes.
Fixes#321. Due to the extremely large quantity of comments on a
typical Motte post, 'hot' sorting logic underflowed an intermediate
value. Roughly:
|(-1 000 000) * (103 [votes] + 1 + 2723 [comments] / 1)| > 2^31
We resolve this by reducing the coefficient from 1e6 to 1e5, which
reduces precision of intermediate calculations somewhat, and by
dividing #comments by 10 rather than 1, which better matches Motte
user behavior regardless: Users comment much more often than vote.
This buys us two orders of magnitude more headroom before out-of-
bounds. Shouldn't be an issue until the CW thread reaches ~200k
comments.
Moves behavior in api_comment that updates stateful counters and
generates notifications into a function which can also be called
if a filtered comment is approved. Fixes#272.
Incidentally, also fixes#278 by adding another filter to the post
subscribers query during general clean-up/refactoring.
Originally was going to move this function into the Comments model,
since assurances about state (even with side effects) should probably
be made there, but I couldn't find a sane way to untangle the imports.
Resolves root problem of non-admin users seeing comments they shouldn't
by JOINing on the appropriate fields and including them in the WHERE
clause of the query.
In the process, was also able to remove some unperformant queries
that used (potentially extremely long) lists passed to WHERE clauses in
lieu of proper JOINs.
