mirror of
https://github.com/evennia/evennia.git
synced 2026-03-19 06:16:31 +01:00
81 lines
3.6 KiB
ReStructuredText
81 lines
3.6 KiB
ReStructuredText
Giving permissions to your staff
|
|
================================
|
|
|
|
*OBS: This gives only a brief introduction to the access system. Locks
|
|
and permissions are fully detailed* `here <Locks.html>`_.
|
|
|
|
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,
|
|
object #1. This is the all-powerful server-owner account. A superuser
|
|
account has access to everything and no locks affect them. Technically
|
|
the superuser not only has all access, it even 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. Usually there is no need to have but one superuser.
|
|
|
|
Assigning permissions
|
|
---------------------
|
|
|
|
Whereas permissions can be used for anything, those put in
|
|
settings.PERMISSION\_HIERARCHY will have a ranking relative each other
|
|
as well. By default Evennia creates the following hierarchy:
|
|
|
|
#. *Immortals* - these basically have all the same access as superusers
|
|
(except that they do not sidestep the Permission system). Assign only
|
|
to really trusted server-admin staff.
|
|
#. *Wizards* can do everything except affecting the server functions
|
|
itself. 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* has 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, 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
|
|
use the ``@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/add *Tommy = Immortals
|
|
|
|
The ``*`` makes 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).
|
|
|
|
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
|
|
the ``@quell`` command you can change so that the Character's permission
|
|
takes precedence instead:
|
|
|
|
::
|
|
|
|
@quell
|
|
|
|
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 permission will still be used.
|