Ban database refactor (#42495)
* Ban DB refactor seems to work at a basic level for PostgreSQL
* New ban creation API
Supports all the new functionality (multiple players/addresses/hwids/roles/rounds per ban).
* Make the migration irreversible
* Re-implement ban notifications
The server ID check is no longer done as admins may want to place bans spanning multiple rounds irrelevant of the source server.
* Fix some split query warnings
* Implement migration on SQLite
* More comments
* Remove required from ban reason
SS14.Admin changes would like this
* More missing AsSplitQuery() calls
* Fix missing ban type filter
* Fix old CreateServerBan API with permanent time
* Fix department and role ban commands with permanent time
* Re-add banhits navigation property
Dropped this on accident, SS14.Admin needs it.
* More ban API fixes.
* Don't fetch ban exemption info for role bans
Not relevant, reduces query performance
* Regenerate migrations
* Fix adminnotes command for players that never connected
Would blow up handling null player records. Not a new bug introduced by the refactor, but I ran into it.
* Great shame... I accidentally committed submodule update...
* Update GDPR scripts
* Fix sandbox violation
* Fix bans with duplicate info causing DB exceptions
Most notably happened with role bans, as multiple departments may include the same role.
* initial visual nubody
* oops overlay
* im so pheeming rn
* conversion...
* tests
* comeback of the underwear
* oops eyes
* blabbl
* zeds
* yaml linted
* search and visible count constraints
* reordering
* preserve previously selected markings colors
* fix test
* some ui niceties
* ordering
* make DB changes backwards-compatible/downgrade-friendly
* fix things again
* fix migration
* vulpkanin markings limit increase
* wrapping
* code cleanup and more code cleanup and more code cleanup and more code cleanup and
* fix slop ports
* better sampling API
* make filter work + use the method i made for its intended purpose
* fix test fails real quick
* magic mirror cleanup, remove TODO
* don't 0-init the organ profile data
* remove deltastates
---------
Co-authored-by: Princess Cheeseballs <66055347+Pronana@users.noreply.github.com>
* Persist construction menu favorites to player profile
* Use `ProtoId`s for construction favorites
* Validate construction favorites updates from the client
* Actually await the async database call
* Add loadout names
Did it for AI, breaking change for pgsql + migrations in general. Nothing atm uses it.
* the box
* Spawning cherry pick
* Fix nit
* revert
* Final cleanup
* Real
* Name UI fix
* Migrations
* a
* Review
* Re-run migrations
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
This should be the primary changes for the future-proof "Modern HWID" system implemented into Robust and the auth server.
HWIDs in the database have been given an additional column representing their version, legacy or modern. This is implemented via an EF Core owned entity. By manually setting the column name of the main value column, we can keep DB compatibility and the migration is just adding some type columns.
This new HWID type has to be plumbed through everywhere, resulting in some breaking changes for the DB layer and such.
New bans and player records are placed with the new modern HWID. Old bans are still checked against legacy HWIDs.
Modern HWIDs are presented with a "V2-" prefix to admins, to allow distinguishing them. This is also integrated into the parsing logic for placing new bans.
There's also some code cleanup to reduce copy pasting around the place from my changes.
Requires latest engine to support ImmutableArray<byte> in NetSerializer.
* Beginnings of making the breadmemes jobs easier
* stuff
* stuff pt. 2
* Stuff pt.3
* Stuff I forgot last time
* Basic whitelist
Only people that are added to the whitelist with the addwhitelist command will be able to join. I call this the "legacy" whitelist
* Remove always deny condition in favor of just breaking if playtime check fails
* Change default whitelist
Default whitelist is now the "legacy" whitelist.
* localization
* Admin check
* minor spelling change
* Fix build
* Whitelist message
* Fix vars not being datafield and spelling mistakes
* Minor spelling mistake
* Change config for salamander
* Reviews and stuff
* Add summaries
* Fix whitelists
* Forgot to add a datafield
* Fixing stuff I guess
* Reuse admin remarks to reduce load when connecting.
* Update log messages to be verbose instead of debug
* Reviews
* whoops
* Explain a bit more how whitelist checking works
* Apply CE's review
* Append Membership to Blacklist and Whitelist conditions
* Fix review comments
* Uncapitalize playerConnectionWhitelist, add to ignored client prototypes
* Make note count field work
* Fix cvar for thingy
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
To help out admins, so they can easily fill out datacenter bans and stuff. Supports ban exemption flags and everything.
This is for use with SS14.Admin so it's just DB models here.
How can ONE DATABASE COLUMN have so many cursed issues I don't know, but it certainly pissed off the devil in its previous life.
The start_date column on round entities in the database was added by https://github.com/space-wizards/space-station-14/pull/21153. For some reason, this PR gave the column a nonsensical default value instead of making it nullable. This default value causes the code from #25280 to break. It actually trips an assert though that's not what the original issue report ran into.
This didn't get noticed on wizden servers because we at some point backfilled the start_date column based on the stored admin logs.
So I change the database model to make this column nullable, updated the C# code to match, and made the existing migration set the invalid values to be NULL instead. Cool.
Wait how's SQLite handle in this scenario anyways? Well actually turns out the column was *completely broken* in the first place!
The code for inserting into the round table was copy pasted between SQLite and PostgreSQL, with the only difference being that the SQLite key manually assigned the primary key instead of letting SQLite AUTOINCREMENT it. And then the code to give a start_date value was only added to the PostgreSQL version (which is actually in the base class already). So for SQLite that column's been filled up with the same invalid default the whole time.
Why was the code manually assigning a PK? I checked the SQLite docs for AUTOINCREMENT[1], and the behavior seems appropriate.
I removed the SQLite-specific code path and it just seems to work regardless. The migration just sets the old values to NULL too.
BUT WAIT, THERE'S MORE!
Turns out just doing the migration on SQLite is a pain in the ass! EF Core has to create a new table to apply the nullability change, because SQLite doesn't support proper ALTER COLUMN. This causes the generated SQL commands to be weird and the UPDATE for the migration goes BEFORE the nullability change... I ended up having to make TWO migrations for SQLite. Yay.
Fixes#26800
[1]: https://www.sqlite.org/autoinc.html
Fixes#26211
Admin messages now have separate "seen" and "dismissed" fields. The idea is that an admin should be able to tell whether a user pressed the "dismiss for now" button. Instead of using "seen" as "show this message to players when they join", "dismissed" is now used for this.
Existing notes in the database will automatically be marked as dismissed on migration. A note cannot be dismissed without being seen (enforced via constraint in the database too, aren't I fancy).
As part of this, it has become impossible for a player to play without dismissing the message in some form. Instead of a shitty popup window, the popup is now a fullscreen overlay that blocks clicks behind it, making the game unplayable. Also, if a user somehow has multiple messages they will be combined into one popup.
Also I had enough respect for the codebase to make it look better and clean up the code somewhat. Yippee.
Role bans (#6703) seemed to have changes to the DB model from after the migrations were created. This means a bunch of constraints/indices changed names and this wasn't reflected in a migration yet.
* Step 1 of porting; grabbed most of the files via patches.
* Add species field to the DB
* Appearance patches for slimes.
* Fix the db test.
* Add slime's biocompat.
* slimby
* Fixes, allow specifying if a species is playable or not.
* Update Content.Client/Preferences/UI/HumanoidProfileEditor.xaml.cs
Co-authored-by: Javier Guardia Fernández <DrSmugleaf@users.noreply.github.com>
* Update Content.Client/Preferences/UI/HumanoidProfileEditor.xaml.cs
Co-authored-by: Javier Guardia Fernández <DrSmugleaf@users.noreply.github.com>
* Update Content.Client/Preferences/UI/HumanoidProfileEditor.xaml.cs
Co-authored-by: Javier Guardia Fernández <DrSmugleaf@users.noreply.github.com>
* Address reviews.
* Address reviews.
* make an if-case.
* Fix a goof where species wouldn't get shown in the editor correctly (it'd always default to human)
Co-authored-by: Javier Guardia Fernández <DrSmugleaf@users.noreply.github.com>
* Add admin logging, models, migrations
* Add logging damage changes
* Add Log admin flag, LogFilter, Logs admin menu tab, message
Refactor admin logging API
* Change admin log get method names
* Fix the name again
* Minute amount of reorganization
* Reset Postgres db snapshot
* Reset Sqlite db snapshot
* Make AdminLog have a composite primary key of round, id
* Minute cleanup
* Change admin system to do a type check instead of index check
* Make admin logs use C# 10 interpolated string handlers
* Implement UI on its own window
Custom controls
Searching
Add admin log converters
* Implement limits into the query
* Change logs to be put into an OutputPanel instead for text wrapping
* Add log <-> player m2m relationship back
* UI improvements, make text wrap, add separators
* Remove entity prefix from damaged log
* Add explicit m2m model, fix any players filter
* Add debug command to test bulk adding logs
* Admin logs now just kinda go
* Add histogram for database update time
* Make admin log system update run every 5 seconds
* Add a cap to the log queue and a metric for how many times it has been reached
* Add metric for logs sent in a round
* Make cvars out of admin logs queue send delay and cap
* Merge fixes
* Reset some changes
* Add test for adding and getting a single log
* Add tests for bulk adding logs
* Add test for querying logs
* Add CallerArgumentExpression to LogStringHandler methods and test
* Improve UI, fix SQLite, add searching by round
* Add entities to admin logs
* Move distinct after orderby
* Add migrations
* ef core eat my ass
* Add cvar for client logs batch size
* Sort logs from newest to oldest by default
* Merge fixes
* Reorganize tests and add one for date ordering
* Add note to log types to not change their numeric values
* Add impacts to logs, better UI filtering
* Make log add callable from shared for convenience
* Get current round id directly from game ticker
* Revert namespace change for DamageableSystem
1. Can only have one high-priority job now. This actually got messed up for at least 10 people in the production DB and I fixed them manually.
2. Can't have duplicate jobs with the same name on the same profile.
