* Add new /casino route and template
* Consolidate lottery into casino and add initial template for slots
* Change /lottery route to /casino and replace icon with usd symbol and change sitewide const to reflect change
* Hook up new slots method to casino
* Enable Marseybux spending in casino slots
* Add UI for playing blackjack in casino
* First connection of blackjack UI to backend
* Add protective clause thanks to help from carpathianflorist.
* Create new Casino_Game relation and persist inside of blackjack
* Connect new slots behavior to Casino_Game table
* Create UI action management logic
* Add blackjack game status checker which adds persistence for blackjack
* Gonna handle this better, hold on
* Reorganize blackjack helper methods
* Reorganize casino.js to account for new changes
* Connect up to frontend
* Little changes ya know
* Display a message when winning in Blackjack
* Fix some issues with double down and insure
* Revert "remove owoify-py from requirements"
This reverts commit 4454648ea2.
* A little casino styling change
* Reorganize into a casino block
* Smallenize the card'
* Remove references to old game data on comments
* Add sql migration file
* Remove logic to drop old columns
* Fix two forgotten conflicts
Permabanning already prevents users from initiating new DMs, and we
complete this by preventing replying to existing DM chains.
New modmails may still be initiated, and existing modmails may still
be replied to.
Getting the basic hats frontend changes into master so my branch stops
diverging from the templates. Migrates the existing cakeday partyhat
functionality to the new system also.
Establishes a (hopefully) static interface for PFP hat display:
- Hat image assets are 100px w x 130px h and anchored to the bottom-
left corner of pfps.
- User.hat_active provides either empty string or the internal
string identifier for active user hat.
- User.hat_tooltip provides mouseover text. Likely only to be used
for cakeday hats on one's cakeday.
Additionally, per discussion with Carp, PFPs in comments and posts
increased from 25px diameter to 30px.
Implemented for LGB but can likely be used for WPD and other future
sites. Similar to a reddit post flair. Provides:
- Admin panel for Category management.
- Category selection on post submission.
- 'Recategorize' post action.
Initially requested by LGB. However, extended to all sites for
consistency: JL3s can add mods to any hole, so removal of mods seems
symmetrically permitted.
The one expansion of privilege regards removal of early mods on the
mod list. However, I believe this to be minimally destructive because
there is no logic to e.g. delete unmodded holes. Tools that can be
used imprudently, though without catastrophic consequences, are
generally extended to all JL3.
Original work started for WPD and LGB, who wish to restrict flags
visibility in the UI based on admin_level. To support this change and
upcoming changes, `const.PERMS: string -> int` was created.
Potentially targetting a future design where Permissions is a proper
business object integrated with the User model; however, for now just
looking toward getting admin_level magic numbers centralized.
This commit applies PERMS to: create_hole, flags visibility in UI,
flag removal in UI & backend. Flag visibility in Comment & Submission
json_raw methods is unaffected to avoid needing a user object to
build the JSON.
The changes to helpers/get.py @ get_user(...) in a6b7fed2fc resulted
in `is_blocking` no longer being present on all User objects retrieved
via `get_user`. This triggered a latent identifier shadow where the
property method `User.is_blocking` on the User model caused checks for
blocks on objects retrieved via `get_user` to always return True.
Notably: when the get_user return value left `is_blocking` unset and
thus implied False, the following expression yielded True due to the
presence of the first-class function at the same identifier:
hasattr(user, 'is_blocking') and user.is_blocking
* poll rework
* forgot to do joinedload on comments
* Fix logic errors with voting, SQL syntax.
Kitchen sink commit from review of poll-rework changes:
1. Fix seed-db.sql syntax error.
2. Fix SQL patch file duplication of *submissions* tables rather
than one set of submissions and one for comments.
3. Start makeshift SQL patch folder, since this is a large change
that contributors may wish to apply to their local instances.
4. Fix checkbox (non-`exclusive`) polls being unable to be
unchecked. For consistency with `exclusive` polls, they should.
5. Fix changing the option of an `exclusive` poll when both
exclusive and non-exclusive options are present in one comment/
post causing the non-exclusive options to become unchecked.
(which, by my reading of SQLAlchemy `Query.one_or_none()`
really could break quite badly in some cases).
* link relationships with their counterparts
* small modification to poll unchecking
Co-authored-by: TLSM <duolsm@outlook.com>