This change meant several changes to the lock and permission functionality, since it becomes important if permissions are assigned on the Player or on their Character (lock functions pperm() and pid() etc check on Player rather than Character). This has the boon of allowing Admins to switch and play/test the game as a "Low access" character as they like.
Plenty of bug fixes and adjustments. Migrations should make sure to move over all data properly.
attributes on objects. Behind the scenes, only the DBREF is stored since storing dbobjects cannot be pickled. One used to be able to store single objects this way, but objects hidden in nested iterable structures were not found. Note that ONLY lists and dictionaries are supported to store on attributes - custom iterables will be stored and retrieved as a generic list instead - this is a tradeoff to be able to store database objects.
To migrate, give the following commands from game/:
migrate.py migrate objects
migrate.py migrate scripts
migrate.py migrate players
- This implements an updated, clearer and more robust access system. The policy is now to lock that which is not explicitly left open.
- Permission strings -> Lock strings. Separating permissions and locks makes more sense security-wise
- No more permissiongroup table; permissions instead use a simple tuple PERMISSIONS_HIERARCHY to define an access hierarchy
- Cleaner lock-definition syntax, all based on function calls.
- New objects/players/channels get a default security policy during creation (set through typeclass)
As part of rebuilding and testing the new lock/permission system I got into testing and debugging several other systems, fixing some
outstanding issues:
- @reload now fully updates the database asynchronously. No need to reboot server when changing cmdsets
- Dozens of new test suites added for about 30 commands so far
- Help for channels made more clever and informative.
