* Use context aware groups
* Revert "Use context aware groups"
This reverts commit 5adc6ef7
* Keep luckperm contexts after authentication
* Code cleanup
* Code cleanup
* Fix nullpointer for context maps
* Code cleanup
* Use uuids for sqlite and postgresql
* Revert "Use uuids for sqlite and postgresql"
This reverts commit 05296e5f23bd4379a89647656f08432c718e6f9c.
* Cleanup imports
* Fix test
Co-authored-by: David Maes <david.maes@kbc.be>
* #1874 Introduce individual ConsoleLogger instance per class
- Create ConsoleLoggerFactory from which a separate logger can be created for each class
- Allows to support individual log level settings in the future
* Fix CodeStyle issue
* Replace full class name with import
* Update usages after merge from master
Rough version.
- Introduces a limbo player state on the LimboPlayer, allowing us to add further mandatory actions between successful (password) authentication and the ability to play on the server
- Overloaded method with (String, String...) as args was problematic as it could be confusing on its own and also confusing with the (CommandSender, String...) flavor
- Remove abstract captcha manager in favor of a primitive captcha code storage (composition over inheritance)
- Supply player when checking captcha code for further usage (fixes open point from previous commit)
- Couple AuthGroupHandler closer to the LimboService: whenever a limbo player is restored, the auth group should be restored as well. This fixes some consistency issues.
- Move AuthGroupHandler into limbo package and make it package-private
- Change permission handler to skip any empty groups (prevents odd command output e.g. for BukkitPermissions)
- Remove SingleFilePersistenceHandler: DistributedFilesPersistenceHandler with segment size 1 can be used instead
- Rename SegmentFilesPersistenceHolder to DistributedFilesPersistenceHandler
- Rename SeparateFilePersistenceHandler to IndividualFilesPersistenceHandler to match LimboPersistenceType entry
- Add link to limbo page on Wiki in the settings
- On startup / reload the playerdata folder is scanned for old segment files, whose data is migrated before they are deleted
- Add tests for segment files persistence holder
- Instead of one huge file or a file for each player, allow the user to define how many files he wants to distribute the LimboPlayers over. This is based on a function that creates a String (segment ID) based on the player's UUID.
- Introduce configurable storage mechanism
- LimboPersistence wraps a LimboPersistenceHandler, of which there are multiple implementations
- Outside of the limbo.persistence package, classes only talk to LimboPersistence
- Restore the way of persisting to JSON from 5.2 (SeparateFilePersistenceHandler)
- Add handling for stored limbo players
- Merge any existing LimboPlayers together with the goal of only keeping one version of a LimboPlayer: there is no way for a player to be online without triggering the creation of a LimboPlayer first, so we can guarantee that the in-memory LimboPlayer is the most up-to-date, i.e. when restoring limbo data we don't have to check against the disk.
- Create and delete LimboPlayers at the same time when LimboPlayers are added or removed from the in-memory map
- Catch all exceptions in LimboPersistence so a handler throwing an unexpected exception does not stop the limbo process (#1070)
- Extend debug command /authme debug limbo to show LimboPlayer information on disk, too
- Extract some logic into LimboServiceHelper to keep LimboService slim
- Create LimboServiceHelper#merge to merge two LimboPlayers associated with a Player. E.g. if an admin unregisters an online player that has not logged in, the creation of a LimboPlayer is triggered while there already is one in LimboService
- Introduce options to define how allow flight, fly & walk speed should be restored from LimboPlayer
- Create consistency tests for line length in SectionComments methods and to ensure that all SettingsHolder classes are part of the returned ConfigurationData
HaHaWTH