<p>There are strictly speaking two types of users in Evennia, the <em>super user</em> and everyone else. The
superuser is the first user you create, object <codeclass="docutils literal notranslate"><spanclass="pre">#1</span></code>. This is the all-powerful server-owner account.
Technically the superuser not only has access to everything, it <em>bypasses</em> 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 <codeclass="docutils literal notranslate"><spanclass="pre">@quell</span></code> below). Usually there is no need to have
<p>Whereas permissions can be used for anything, those put in <codeclass="docutils literal notranslate"><spanclass="pre">settings.PERMISSION_HIERARCHY</span></code> will have
a ranking relative each other as well. We refer to these types of permissions as <em>hierarchical
permissions</em>. When building locks to check these permissions, the <codeclass="docutils literal notranslate"><spanclass="pre">perm()</span></code><aclass="reference internal"href="../Components/Locks.html"><spanclass="doc std std-doc">lock function</span></a> is
<li><p><strong>Developers</strong> basically have the same access as superusers except that they do <em>not</em> 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 <codeclass="docutils literal notranslate"><spanclass="pre">@py</span></code> command that allows the execution of arbitrary Python code on the
command line.</p></li>
<li><p><strong>Admins</strong> can do everything <em>except</em> affecting the server functions themselves. So an Admin
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.</p></li>
<li><p><strong>Builders</strong> - have all the build commands, but cannot affect other accounts or mess with the
<p>A user having a certain level of permission automatically have access to locks specifying access of
a lower level.</p>
<p>To assign a new permission from inside the game, you need to be able to use the <codeclass="docutils literal notranslate"><spanclass="pre">@perm</span></code> command.
This is an <em>Developer</em>-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 <em>Developer</em> access (or is superuser), you assign
a new account “Tommy” to your core staff with the command</p>
<p>We use a switch or the <codeclass="docutils literal notranslate"><spanclass="pre">*name</span></code> format to make sure to put the permission on the <em>Account</em> and not on
any eventual <em>Character</em> that may also be named “Tommy”. This is usually what you want since the
Account will then remain an Developer regardless of which Character they are currently controlling.
To limit permission to a per-Character level you should instead use <em>quelling</em> (see below). Normally
permissions can be any string, but for these special hierarchical permissions you can also use
<p>When developing it can be useful to check just how things would look had your permission-level been
lower. For this you can use <em>quelling</em>. Normally, when you puppet a Character you are using your
Account-level permission. So even if your Character only has <em>Accounts</em> level permissions, your
<em>Developer</em>-level Account will take precedence. With the <codeclass="docutils literal notranslate"><spanclass="pre">@quell</span></code> command you can change so that the
