Do not merge this without coordinating with your server's host.
Slightly refactors the way we handle IP intel.
You can still use the old data stored in the database.
Adds the ability to automatically reject connections determined by
config flags.
We used to have IP intel to check for VPNs, although it was disabled due
to being bad and unhelpful.
This refactor should make it much more manageable for hosts and admins.
This adds a new SQL table `ipintel_whitelist`
Look at the schema!
🆑
admin: The return of IPIntel
/🆑
---------
Co-authored-by: MrStonedOne <kyleshome@gmail.com>
Co-authored-by: oranges <email@oranges.net.nz>
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Adds functionality for administrators to toggle playtime job exemption
for ckeys on a job basis
Admins go through player panel to access the menu and they can toggle
that with just one click
The action is logged, announced to all admins, and if the player is
logged on with that ckey, it is announced to him aswell
The exemption status is saved on the DB, a new `bubber_schema.sql` needs
to be ran to add the new table to the DB
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
<!-- Please make sure to actually test your PRs. If you have not tested
your PR mention it. -->
## Why It's Good For The Game
It was requested
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Proof Of Testing
Included screenshots in the About section
<!-- Compile and run your code locally. Make sure it works. This is the
place to show off your changes! We are not responsible for testing your
features. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
admin: administrators can now toggle job playtime exemption by job basis
for players
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
<!-- By opening a pull request. You have read and understood the
repository rules located on the main README.md on this project. -->
---------
Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com>
* Initial commit, not even half-done yet
* A second commit as I stumble towards a working solution
* Theeere we go, another step , I suppose
* fixes and one prompt per player
* yaya
* a
* okaaay, a step further
* not done yet but soon
* Theeere we go...
* feeex
* no interact till ss done
* Update maturity_subsystem.dm
* Okay, maybe it works now
* Ready for tests
* At last... now to test with a db.
* oh well, it's not like it needs to be the first one to init
* undoes the changelog clusterfuck
* now undoes it for real
* autoformatter-b-gone
* okay we don't want it on by default
* Well, it is ambiguous now that I look at it.
* Okay, now it should work 95%
* Oh well
* This should be straight up faster
* y u no auto tick
---------
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Initial draft, most of the stuff is implemented, not really tested or cleaned up yet
* Refactors the handling into a datum-based approach, for more abstraction
* Added migration, properly hooked up the verb to the new system
* Removed some more dead code
* Fixes some missing stuff from the .dme because VSC is stupid sometimes with merge conflicts
* Fixes the schema
* Wow I was really getting tired huh
* A fool, I say, a fool!
* I hate lists of lists I hate lists of lists I hate lists of lists
* I somehow missed this one twice. TWICE!
* This won't actually work if it's defaulting to true, lmao
* Makes it not log stuff if the adding or removing of players is unsuccessful
* Adds a way to update all of the unlock_contents for preferences datums once the donator list is initialized
* Runs update_prefs_unlock_content on mob Login() (hopefully this helps)
* Fixes the bajillion of runtimes caused by my dumb ass trying to make some client calls on ckeys
* Man I was really tired that day
* I had this ready for three hours and forgot to push it
* Log telemetry connections in DB (#63435)
About The Pull Request
Logs tgui telemetry connections into the database. Useful since they are normally capped to 5.
Does not change the fact that the "banned account in connection history" part is still based on your history at that time. I figured it could potentially be very slow to go through your entire database history.
* Fix IPs in telemetry_connections not being unsigned (#63573)
About The Pull Request
Fixes IPs not being unsigned, causing problems where they get capped if the IP is too big.
Not tested.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Allows players to send more visible adminhelps when no admins are on, which'll definitely alert admins
* db portion sorted out
* now it really is
* should work about fine
* one last touch
* well, one more
* also botched comment
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com>
* Better accomodation of multiple servers using the same database.
* updated the PR number in readme.md
* Updated the database_changelog description.
* Oopsie.
* Cosmetic touch and sql query fixes.
* Opsie wopsie
* Oopsie x2
* Fugg
* Fix sql changelog (#57972)
Fixed bad SQL that I originally wrote in the changelog for 5.11, anyone trying to update their schema from < 5.11 up would notice this.
* Fix sql changelog
Co-authored-by: Bobbahbrown <bobbahbrown@gmail.com>
* Added the SQL logging.. waf
* I dont know why CI does not like my sql......
* I think i fixed the sql....
* Attempt #1 to make linter happy
* Shhh linter, it will be over soon
Just breath into this cloth... ignore the chloroform smell.
(Add a Preprocesser statement, to make the SpacemanDMM linter ignore the SQL code in a mob atom obj, that causes it to trigger its hard coded test for stoplag.
This only does not trigger on other SQL, as there is hard coded exception in SpacemanDMM that ignores the other objects. the better fix would be to update SpacemanDMM to add this into the exclusion. but this change at least allows the PR to be merged finally)
Co-authored-by: MissFox <github@aesir.org.uk>
* Sets the charset and collation for the SQL schema to utf8mb4 (#56060)
Changes the charset and collation in the SQL schema to utf8mb4 (which is default in ubuntu 20.04 and debian 10 for MariaDB). This solves all the problems with russian or other non-latin1 characters in many cases related to the use of the database, because surprisingly the rest is already ready for such use cases.
I am not adding any SQL script to migrate from latin1 to utf8mb4, as this is an extremely destructive action. It must be performed manually with the data of all tables backed up before doing so.
However, this can be done by using the following queries, one time for database:
ALTER DATABASE databse_name CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
and one for each table:
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
* Sets the charset and collation for the SQL schema to utf8mb4
Co-authored-by: Vladimir Veisman <v.veisman@fl45h13.me>
* SQL Schema Version 5.11 / Add indices for ticket table to support Statbus operations (#53541)
* I hope you're proud of yourselves. You've driven away another customer! It's baffling, I tell you! Your deep rooted lack of self-control only fosters failure in every endeavor we undertake! I mean, it's always one step forward and two steps back! Why? Don't you see the example I try to set for you?
* thanks jordie
* SQL Schema Version 5.11 / Add indices for ticket table to support Statbus operations
Co-authored-by: Bobbahbrown <bobbahbrown@gmail.com>
* Overhauls discord verification system (#53289)
This completely replaces the previous verification system, for one that
will interoperate with a discord redbot instance that uses the cogs
located at you github.com/optimumtact/orangescogs
This cuts out several steps in the system, but it also leaves alone the
existing notify system (which just uses a file list of discord ids) as a
record of who to notify
SQL changes required for the new database system
Version 5.10, 7 August 2020, by oranges
Changes how the discord verification process works.
Adds the discord_links table, and migrates discord id entries from
player table to the discord links table in a once off operation and then
removes the discord id on the player table
The user connects to any tg server, and uses the "Verify Discord
Account" verb, this generates a six word one time use token, with a 4
hour time validity period (defined as 4 hours from the timestamp value)
in the discord links table.
This one time token, and the ckey of the user are stored in
discord_links
At this point the entire DM side is done, this is all it does
* Overhauls discord verification system
Co-authored-by: oranges <email@oranges.net.nz>
An almost complete rework of how creating polls, their data and voting on them is handled.
Instead of repeatedly querying for poll data, running polls are loaded at runtime into poll_question and poll_option datums that stores all the needed variables for both. This datum is then used for creating, editing and accessing poll data. The database is only contacted when saving changes or votes.
Creating polls and options is now done with a html window instead of a series of popups akin to how the banning panel works. The form data is parsed and error-checked before passing to be saved.
This is done in two stages, first time a poll's details are entered and it must be initialized (created as a datum) before options can be added and all of both are saved to the database. Instructions about how this work are shown on the poll creation window.
A new field for polls has been added, subtitles, which is text only shown when a poll is opened by a player instead of on the list of polls. Intended so the actual question text can be kept to only a name and important information about a poll goes in a subtitle.
All polls can now have revoting enabled on them.
Polls can have a starting datetime specified, this can be in the past but why would you do that?
Polls and options can be edited once created, excluding the type of a poll. Doing so will by default clear all existing poll votes. Votes can also be cleared by a button.
The handling of how votes are processed has been adapted for the datum system but is on the whole not functionally that different aside from poll validation not being roughly copypasted across each poll type's vote proc
All poll tables now have a deleted column for retaining 'deleted' data.
poll_question has also gained the columns created_datetime, subtitle, allow_revoting, their function explained above, and a change of idx_pquest_time_admin to idx_pquest_time_deleted_id.
A stored procedure set_poll_deleted has been added. This is called when setting a poll as deleted to avoid needing 4 separate queries from the server or one fairly long 4-way joined
Create Poll verb is renamed to Server Poll Management
It came up that this isn't recorded, only logged.
Technically needs syncing merge with schema change but only deleting notes would break from this and tbh that isn't done very often so I think it'd be fine to yolo.
* DB ticket procs
* Schema changes for DB tickets
* Schema version update
* Fixes requested by Jordie
* SQL updates
Adds a recipient column
* Still one dangling issue where this DOESN'T WORK
* Alright, this should work
* Requested SQL fixes
* Rogue changes
* less bad defaults
* utf8 for the utf8 gods
* aaaaaa
* Update tgstation_schema_prefixed.sql
* Update tgstation_schema.sql
* Update database_changelog.txt
Co-authored-by: Jordie <4343468+Jordie0608@users.noreply.github.com>
Drops byond hub support and adds score and top 50 browsers.
Requires DB changes and manual creation of migration script if we want to keep old achievements so no random merges please.
* Notify System
* V2
* Adds a hint
* Stoned fixes round 1
* Use grammar wells I can
* This didnt work
* I wish you could test on TGS without committing
* Jordie fixes round 1
* oops
* This took way longer than it should have taken
* Adds in endnotify for serverops
* Spacing
Supports disabling stickybans for a round, exempting a key from matching a stickyban, and it now also detects rogue stickybans before anybody currently connected even gets disconnected. (new matches trigger a 5 second sleep and abort enforcement if enough other new matches happen in that timeframe)
Spiritual successor and extension to #17798, an almost entire rebuild of the SQL ban system backend and interface.
Bantypes are removed per #8584 and #6174. All bans are now 'role bans', server bans are when a ban's role is server. Admin bans are a column, meaning it's possible to ban admins from jobs.
Bans now have only an expiry datetime, duration is calculated from this when queried.
unbanned column is removed as it's superfluous, checking unban status is now done through checking unban_datetime. unban_round_id column added. Each ip and computerid columns rearranged so ip is always first, like in other tables. Bans now permit a null ckey, ip and computerid.
Ban checking is split into two procs now is_banned_from() does a check if a ckey is banned from one or more roles and returns true or false. This effectively replaces jobban_isbanned() used in simple if() statements. If connected a client's ban cache is checked rather than querying the DB. This makes it possible for a client connected to two or more servers to ignore any bans made on one server until their ban cache is rebuilt on the others. Could be avoided with cross-server calls to update ban caches or just the removal of the ban cache but as is I've done neither since I think it's enough of an edge case to not be worth it.
The second proc is is_banned_from_with_details(), this queries the DB for a role ban on a player's ckey, ip or CID and returns the details. This replaces direct queries in IsBanned.dm and the preferences menu.
The legacy ban system is removed.
The interfaces for banning, unbanning and editing bans have been remade to require less clicking and easier simultaneous operations. The banning and jobban panel are combined. They also store player connection details when opened so a client disconnecting no longer stops a ban being placed.
New banning panel:
Key, IP and CID can all be toggled to allow excluding them from a ban.
Checking Use IP and CID from last connection lets you enter only a ckey and have the DB fill these fields in for you, if possible.
Temporary bans have a drop-menu which lets you select between seconds, minutes, hours, days, weeks, months and years so you don't need to calculate how many minutes a long ban would be. The ban is still converted into minutes on the DB however.
Checking any of the head roles will check both of the boxes for you.
The red role box indicates there is already a ban on that role for this ckey. You can apply additional role bans to stack them.
New unbanning panel:
Unbanning panel is now separate from the banning panel but otherwise functionally the same.
Ban editing panel:
Actually just a modified banning panel, all the features from it work the same here.
You can now edit almost all parameters of a ban instead of just the reason.
You can't edit severity as it's not really part of the ban.
The panels have been tested but I've not been able to get my local server to be accessible so ban functionality isn't properly confirmed. Plenty of testing will be required as I'd rather not break bans.
cl
admin: Ban interface rework. The banning and unbanning panels have received a new design which is easier to use and allows multiple role bans to be made at once.
prefix: Ban search and unbanning moved to unbanning panel, which is now a separate panel to the old banning panel.
/cl
* Adds note_severity and updates dbconfig. New SQL stuff too.
* whoops please don't hack into my database >:^(
* UI change, changed how it's stored in the DB, removed some queries when it returns, changed stuff to key.
* Update sql_message_system.dm
* this was not defined
* random indent
* wait how did this get here
* okay enough web edits I promise
* just kidding I got u
* Update common.css
* Added buttons, changed UI again, standardized the inputs, added severity for appearance bans, fed the dog
* forgot about the banning panel
* added an asset cache
* corrects asset datum var name
Fixes a breaking error and possible injection exploit in
populate_key_2018-07-09.py caused by a key existing from when byond allowed now
blocked characters like ' in usernames e.g.
http://www.byond.com/members/immortaljrosh?format=text
Additionally fixes some unsanitized values in other queries.
