<h1>The Web Admin<aclass="headerlink"href="#the-web-admin"title="Permalink to this headline">¶</a></h1>
<p>The Evennia <em>Web admin</em> is a customized <aclass="reference external"href="https://docs.djangoproject.com/en/4.1/ref/contrib/admin/">Django admin site</a>
used for manipulating the game database using a graphical interface. You
have to be logged into the site to use it. It then appears as an <codeclass="docutils literal notranslate"><spanclass="pre">Admin</span></code> link
the top of your website. You can also go to <aclass="reference external"href="http://localhost:4001/admin">http://localhost:4001/admin</a> when
running locally.</p>
<p>Almost all actions done in the admin can also be done in-game by use of Admin-
or Builder-commands.</p>
<sectionid="usage">
<h2>Usage<aclass="headerlink"href="#usage"title="Permalink to this headline">¶</a></h2>
<p>The admin is pretty self-explanatory - you can see lists of each object type,
create new instances of each type and also add new Attributes/tags them. The
admin frontpage will give a summary of all relevant entities and how they are
used.</p>
<p>There are a few use cases that requires some additional explanation though.</p>
<sectionid="adding-objects-to-attributes">
<h3>Adding objects to Attributes<aclass="headerlink"href="#adding-objects-to-attributes"title="Permalink to this headline">¶</a></h3>
<p>The <codeclass="docutils literal notranslate"><spanclass="pre">value</span></code> field of an Attribute is pickled into a special form. This is usually not
something you need to worry about (the admin will pickle/unpickle) the value
for you), <em>except</em> if you want to store a database-object in an attribute. Such
objects are actually stored as a <codeclass="docutils literal notranslate"><spanclass="pre">tuple</span></code> with object-unique data.</p>
<ol>
<li><p>Find the object you want to add to the Attribute. At the bottom of the first section
you’ll find the field <em>Serialized string</em>. This string shows a Python tuple like</p>
<p>Mark and copy this tuple-string to your clipboard exactly as it stands (parentheses and all).</p>
</li>
<li><p>Go to the entity that should have the new Attribute and create the Attribute. In its <codeclass="docutils literal notranslate"><spanclass="pre">value</span></code>
field, paste the tuple-string you copied before. Save!</p></li>
<li><p>If you want to store multiple objects in, say, a list, you can do so by literally
typing a python list <codeclass="docutils literal notranslate"><spanclass="pre">[tuple,</span><spanclass="pre">tuple,</span><spanclass="pre">tuple,</span><spanclass="pre">...]</span></code> where you paste in the serialized
tuple-strings with commas. At some point it’s probably easier to do this in code though …</p></li>
</ol>
</section>
<sectionid="linking-accounts-and-characters">
<h3>Linking Accounts and Characters<aclass="headerlink"href="#linking-accounts-and-characters"title="Permalink to this headline">¶</a></h3>
<p>In <codeclass="docutils literal notranslate"><spanclass="pre">MULTISESSION_MODE</span></code> 0 or 1, each connection can have one Account and one
Character, usually with the same name. Normally this is done by the user
creating a new account and logging in - a matching Character will then be
created for them. You can however also do so manually in the admin:</p>
<olclass="simple">
<li><p>First create the complete Account in the admin.</p></li>
<li><p>Next, create the Object (usually of <codeclass="docutils literal notranslate"><spanclass="pre">Character</span></code> typeclass) and name it the same
as the Account. It also needs a command-set. The default CharacterCmdset is a good bet.</p></li>
<li><p>In the <codeclass="docutils literal notranslate"><spanclass="pre">Puppeting</span><spanclass="pre">Account</span></code> field, select the Account.</p></li>
<li><p>Make sure to save everything.</p></li>
<li><p>Click the <codeclass="docutils literal notranslate"><spanclass="pre">Link</span><spanclass="pre">to</span><spanclass="pre">Account</span></code> button (this will only work if you saved first). This will
add the needed locks and Attributes to the Account to allow them to immediately
connect to the Character when they next log in. This will (where possible):</p>
<ulclass="simple">
<li><p>Set <codeclass="docutils literal notranslate"><spanclass="pre">account.db._last_puppet</span></code> to the Character.</p></li>
<li><p>Add Character to <codeclass="docutils literal notranslate"><spanclass="pre">account.db._playabel_characters</span></code> list.</p></li>
<li><p>Add/extend the <codeclass="docutils literal notranslate"><spanclass="pre">puppet:</span></code> lock on the Character to include <codeclass="docutils literal notranslate"><spanclass="pre">puppet:pid(<Character.id>)</span></code></p></li>
</ul>
</li>
</ol>
</section>
<sectionid="building-with-the-admin">
<h3>Building with the Admin<aclass="headerlink"href="#building-with-the-admin"title="Permalink to this headline">¶</a></h3>
<p>It’s possible (if probably not very practical at scale) to build and describe
rooms in the Admin.</p>
<olclass="simple">
<li><p>Create an <codeclass="docutils literal notranslate"><spanclass="pre">Object</span></code> of a Room-typeclass with a suitable room-name.</p></li>
<li><p>Set an Attribute ‘desc’ on the room - the value of this Attribute is the
room’s description.</p></li>
<li><p>Add <codeclass="docutils literal notranslate"><spanclass="pre">Tags</span></code> of <codeclass="docutils literal notranslate"><spanclass="pre">type</span></code>‘alias’ to add room-aliases (no type for regular tags)</p></li>
</ol>
<p>Exits:</p>
<olclass="simple">
<li><p>Exits are <codeclass="docutils literal notranslate"><spanclass="pre">Objects</span></code> of an <codeclass="docutils literal notranslate"><spanclass="pre">Exit</span></code> typeclass, so create one.</p></li>
<li><p>The exit has <codeclass="docutils literal notranslate"><spanclass="pre">Location</span></code> of the room you just created.</p></li>
<li><p>Set <codeclass="docutils literal notranslate"><spanclass="pre">Destination</span></code> set to where the exit leads to.</p></li>
<li><p>Set a ‘desc’ Attribute, this is shown if someone looks at the exit.</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">Tags</span></code> of <codeclass="docutils literal notranslate"><spanclass="pre">type</span></code>‘alias’ are alternative names users can use to go through
this exit.</p></li>
</ol>
</section>
</section>
<sectionid="grant-others-access-to-the-admin">
<h2>Grant others access to the admin<aclass="headerlink"href="#grant-others-access-to-the-admin"title="Permalink to this headline">¶</a></h2>
<p>The access to the admin is controlled by the <codeclass="docutils literal notranslate"><spanclass="pre">Staff</span><spanclass="pre">status</span></code> flag on the
Account. Without this flag set, even superusers will not even see the admin
link on the web page. The staff-status has no in-game equivalence.</p>
<p>Only Superusers can change the <codeclass="docutils literal notranslate"><spanclass="pre">Superuser</span><spanclass="pre">status</span></code> flag, and grant new
permissions to accounts. The superuser is the only permission level that is
also relevant in-game. <codeclass="docutils literal notranslate"><spanclass="pre">User</span><spanclass="pre">Permissions</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">Groups</span></code> found on the <codeclass="docutils literal notranslate"><spanclass="pre">Account</span></code>
admin page <em>only</em> affects the admin - they have no connection to the in-game
<p>For a staffer with <codeclass="docutils literal notranslate"><spanclass="pre">Staff</span><spanclass="pre">status</span></code> to be able to actually do anything, the
superuser must grant at least some permissions for them on their Account. This
can also be good in order to limit mistakes. It can be a good idea to not allow
the <codeclass="docutils literal notranslate"><spanclass="pre">Can</span><spanclass="pre">delete</span><spanclass="pre">Account</span></code> permission, for example.</p>
<divclass="admonition important">
<pclass="admonition-title">Important</p>
<p>If you grant staff-status and permissions to an Account and they still cannot
access the admin’s content, try reloading the server.</p>
</div>
<divclass="admonition warning">
<pclass="admonition-title">Warning</p>
<divclass="highlight-none notranslate"><divclass="highlight"><pre><span></span>If a staff member has access to the in-game ``py`` command, they can just as
well have their admin ``Superuser status`` set too. The reason is that ``py``
grants them all the power they need to set the ``is_superuser`` flag on their
account manually. There is a reason access to the ``py`` command must be
considered carefully ...
</pre></div>
</div>
</div>
</section>
<sectionid="customizing-the-web-admin">
<h2>Customizing the web admin<aclass="headerlink"href="#customizing-the-web-admin"title="Permalink to this headline">¶</a></h2>
<p>Customizing the admin is a big topic and something beyond the scope of this
documentation. See the <aclass="reference external"href="https://docs.djangoproject.com/en/4.1/ref/contrib/admin/">official Django docs</a> for
the details. This is just a brief summary.</p>
<p>See the <aclass="reference internal"href="Website.html"><spanclass="doc std std-doc">Website</span></a> page for an overview of the components going into
generating a web page. The Django admin uses the same principle except that
Django provides a lot of tools to automate the admin-generation for us.</p>
<p>Admin templates are found in <codeclass="docutils literal notranslate"><spanclass="pre">evennia/web/templates/admin/</span></code> but you’ll find
this is relatively empty. This is because most of the templates are just
inherited directly from their original location in the Django package
(<codeclass="docutils literal notranslate"><spanclass="pre">django/contrib/admin/templates/</span></code>). So if you wanted to override one you’d have
to copy it from <em>there</em> into your <codeclass="docutils literal notranslate"><spanclass="pre">mygame/templates/admin/</span></code> folder. Same is true
for CSS files.</p>
<p>The admin site’s backend code (the views) is found in <codeclass="docutils literal notranslate"><spanclass="pre">evennia/web/admin/</span></code>. It
is organized into <codeclass="docutils literal notranslate"><spanclass="pre">admin</span></code>-classes, like <codeclass="docutils literal notranslate"><spanclass="pre">ObjectAdmin</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">AccountAdmin</span></code> etc.
These automatically use the underlying database models to generate useful views
for us without us havint go code the forms etc ourselves.</p>
<p>The top level <codeclass="docutils literal notranslate"><spanclass="pre">AdminSite</span></code> (the admin configuration referenced in django docs)
is found in <codeclass="docutils literal notranslate"><spanclass="pre">evennia/web/utils/adminsite.py</span></code>.</p>
<sectionid="change-the-title-of-the-admin">
<h3>Change the title of the admin<aclass="headerlink"href="#change-the-title-of-the-admin"title="Permalink to this headline">¶</a></h3>
<p>By default the admin’s title is <codeclass="docutils literal notranslate"><spanclass="pre">Evennia</span><spanclass="pre">web</span><spanclass="pre">admin</span></code>. To change this, add the
following to your <codeclass="docutils literal notranslate"><spanclass="pre">mygame/web/urls.py</span></code>:</p>
<divclass="highlight-python notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># in mygame/web/urls.py</span>
<spanclass="n">site</span><spanclass="o">.</span><spanclass="n">site_header</span><spanclass="o">=</span><spanclass="s2">"My great game admin"</span>
</pre></div>
</div>
<p>Reload the server and the admin’s title header will have changed.</p>
