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)`
Double XP now has a constant for unixtime to start. Logic around
DXP is designed to only apply to votes made after DOUBLE_XP_ENABLED.
This prevents an exploit in the old implementation where spam voting/
unvoting a post made prior to the DXP start could farm 300 DC/hr/alt.
Also it's more maintainable and comports with the coin_delta changes
to prevent self-vote coin changes.
Re-enable lootboxes in const.py, and update their contents in
awards.py. Additionally, improve appearance in shop.
Upon purchasing a lootbox, users now receive a message informing
them of the contents thereof.
Lootbox backend now properly uses CARP_ID (and checks for the
existence thereof correctly).
Also, minor changes to how const.py whitelists awards.
When ricardo.js was included on a page with ≥1 ricardo but <3
ricardos, the ricardo2 and ricardo3 handlers attempted to modify
non-existent DOM objects. There is now a non-null check before doing
so. Non-null check on ricardo1 isn't strictly necessary; however,
it has been added in case the inclusion of ricardo.js ever is not
conditional on a serverside ricardo quantity check.
Turns out the snippet in templates/comments.html was necessary to
get proper behavior in notifications.
Might come back to debug this later, but people use notifications more
than they deal with edge case self-upvotes, so reverting for now.
The changes to prevent coin fuckery with self-upvoting appear to work
correctly in the wild, so leaving those in place.
Implements feature request to know how many of each badge exists and
to have a 'rarity', a la Steam or PSN badges, relative to number of
non-lurker users.
Because Postgres `COUNT()`s are notoriously costly, /badges has been
memoized for 1hr to avoid a DOS target.
Fixes minor UI bug when removing self-upvote on a comment. Previous
behavior, starting from a new comment:
- Initial state: score 1 from self-upvote, upvote button shows
highlighted as `color: var(--primary)`.
- Click on upvote button to remove self-upvote → button
unhighlights, score displays as 0.
- [reload page]
- Score displays as 0, but button is highlighted.
- Click on upvote button → button unhighlights, score displays
as -1. [If you reload the page now, state is score 0 &
highlighted; no change in serverside votes.]
- Click on upvote again → button highlights, score displays as 0.
- [reload page]
- Score displays as 1, button is highlighted.
Direct cause is `templates/comments.html @ L115-117`. I checked
`api_comment`, though, and it adds a vote on new comments, and that
state change propagates to the template's parameters before it renders,
so I believe the only time this triggers is specifically when a user
has removed their self-upvote. Bug is fixed when testing with L115-117
removed. Is there some other edge case it was meant to solve?
Secondary bugfix: Removing a self-upvote _costs_ you a coin & a
truescore point. I think this is one of the few ways to get negative
dramacoin. I chose to fix it by having self-votes and self-unvotes not
change coins/truecoins. The alternative of having new comments & posts
give the user +1 coin/truecoin would modify site behavior, and you'd
retroactively owe some powerusers thousands of DC & truescore.
Snakes
gooseman
geese-suck
Aevann1