OBS: This gives only a brief introduction to the access system. Locks and permissions are fully detailed here.
The super user¶
There are strictly speaking two types of users in Evennia, the super
user and everyone else. The superuser is the first user you create,
#1. This is the all-powerful server-owner account.
Technically the superuser not only has access to everything, it
bypasses the permission checks entirely. This makes the superuser
impossible to lock out, but makes it unsuitable to actually play-test
the game’s locks and restrictions with (see
@quell below). Usually
there is no need to have but one superuser.
Whereas permissions can be used for anything, those put in
settings.PERMISSION_HIERARCHY will have a ranking relative each
other as well. We refer to these types of permissions as hierarchical
permissions. When building locks to check these permissions, the
perm() lock function is used. By default Evennia creates the
following hierarchy (spelled exactly like this):
- Immortals basically have the same access as superusers except
that they do not sidestep the Permission system. Assign only to
really trusted server-admin staff since this level gives access both
to server reload/shutdown functionality as well as (and this may be
more critical) gives access to the all-powerful
@pycommand that allows the execution of arbitrary Python code on the command line.
- Wizards can do everything except affecting the server functions themselves. So a wizard couldn’t reload or shutdown the server for example. They also cannot execute arbitrary Python code on the console or import files from the hard drive.
- Builders - have all the build commands, but cannot affect other players or mess with the server.
- PlayerHelpers are almost like a normal Player, but they can also add help files to the database.
- Players is the default group that new players end up in. A new player have permission to use tells and to use and create new channels.
A user having a certain level of permission automatically have access to locks specifying access of a lower level.
To assign a new permission from inside the game, you need to be able to
@perm command. This is an Immortal-level command, but it
could in principle be made lower-access since it only allows assignments
equal or lower to your current level (so you cannot use it to escalate
your own permission level). So, assuming you yourself have Immortal
access (or is superuser), you assign a new player “Tommy” to your core
staff with the command
@perm/player Tommy = Immortals
@perm *Tommy = Immortals
We use a switch or the
*name format to make sure to put the
permission on the Player and not on any eventual Character that may
also be named “Tommy”. This is usually what you want since the Player
will then remain an Immortal regardless of which Character they are
currently controlling. To limit permission to a per-Character level you
should instead use quelling (see below). Also remember that the access
group you add is by default in plural (“Immortals”, not “Immortal”) -
since permissions can have any name, the system will not complain if you
assign the wrong one.
Quelling your permissions¶
When developing it can be useful to check just how things would look had
your permission-level been lower. For this you can use quelling.
Normally, when you puppet a Character you are using your Player-level
permission. So even if your Character only has Players level
permissions, your Immortals-level Player will take precedence. With
@quell command you can change so that the Character’s permission
takes precedence instead:
This will allow you to test out the game using the current Character’s permission level. A developer or builder can thus in principle maintain several test characters, all using different permission levels. Note that you cannot escalate your permissions this way; If the Character happens to have a higher permission level than the Player, the Player’s (lower) permission will still be used.