cb1bb4e43b40: Server cleaned out schema.sql for some reason and
it was autocommitted by the sneed cron. This is why the tests fail.
2737a6ca479b: Originally pulled from themotte/rDrama @ 309bf44f12ba.
In light of the fact this is breaking comment previews right now and
the actual XSS threat is unclear, given we sanitize serverside,
this is reverted until I find time to look at it.
Comments of the style e.g. "@TLSM / @TLSM2" would mistakenly be
`sanitize`d to have identical links only on "@TLSM", the latter
instance having a dangling 2 on the end. It seems this is purely an
issue with text formatting; alerts.py @ NOTIF_USERS had no such
issues. The root cause appears to be partly an optimization and
partly the use of str.replace without a count limit.
The award modal note field had a maxLength of 200 characters.
This was retained when repurposing the field for the new flair to be
applied by a flairlock award. However, flairs have a maxLength of 100
characters. award_modal.js now makes this clearer in the UI by
changing the maxLength of note when a flairlock award is picked.
The shop discount from Big Spender badges was incorrectly implemented:
intended behavior was for 2pp per badge. However, the values in
const.py were set as if a user could only have one Spender badge at
once, while user.py @ discount was implemented as if they were
additive. Since users factually do have multiple big spender badges,
the values in const were adjusted to reflect this fact.
Also, lootbox Roller badges now each offer a 1pp discount.
users.py @ discount was improved to check against the `discounts`
keys for appropriate badges, rather than a hardcoded list.
Very strange bug, and I hope this fixes it. User popovers, e.g. on
comments pages when names are clicked, spontaneously stopped working
on my local instance. This parallels occasional reports from others
that their popovers stop working for seemingly no reason.
The primary symptom appeared to be in comments+submission_listing.js
@ popclick(...), which became unable to find any `.popover` elements
in the document, resulting in a console error. Running `bs_trigger(
document)` manually in console after page load always fixed this.
As such, I am assuming this is (hopefully) a timing bug from the
bs_trigger call in header.js running before document ready. The call
now runs on a standard document ready callback boilerplate.
May God have mercy on our souls if this doesn't fix it.
I discovered that running `bs_trigger(document)`
Aevann1
Snakes
Nekobit