2021-05-22 20:12:48 +02:00
|
|
|
# The Web Admin
|
|
|
|
|
|
|
|
|
|
The Evennia _Web admin_ is a customized [Django admin site](https://docs.djangoproject.com/en/3.2/ref/contrib/admin/)
|
2021-05-23 00:18:27 +02:00
|
|
|
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 `Admin` link
|
|
|
|
|
the top of your website. You can also go to [http://localhost:4001/admin](http://localhost:4001/admin) when
|
|
|
|
|
running locally.
|
2021-05-22 20:12:48 +02:00
|
|
|
|
2021-05-23 00:18:27 +02:00
|
|
|
Almost all actions done in the admin can also be done in-game by use of Admin-
|
|
|
|
|
or Builder-commands.
|
2021-05-22 20:12:48 +02:00
|
|
|
|
2021-05-23 00:18:27 +02:00
|
|
|
## Usage
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
There are a few use cases that requires some additional explanation though.
|
|
|
|
|
|
|
|
|
|
### Adding objects to Attributes
|
|
|
|
|
|
|
|
|
|
The `value` 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), _except_ if you want to store a database-object in an attribute. Such
|
|
|
|
|
objects are actually stored as a `tuple` with object-unique data.
|
|
|
|
|
|
|
|
|
|
1. Find the object you want to add to the Attribute. At the bottom of the first section
|
|
|
|
|
you'll find the field _Serialized string_. This string shows a Python tuple like
|
|
|
|
|
|
|
|
|
|
('__packed_dbobj__', ('objects', 'objectdb'), '2021:05:15-08:59:30:624660', 358)
|
2021-10-21 21:04:14 +02:00
|
|
|
|
2021-05-23 00:18:27 +02:00
|
|
|
Mark and copy this tuple-string to your clipboard exactly as it stands (parentheses and all).
|
|
|
|
|
2. Go to the entity that should have the new Attribute and create the Attribute. In its `value`
|
|
|
|
|
field, paste the tuple-string you copied before. Save!
|
|
|
|
|
3. If you want to store multiple objects in, say, a list, you can do so by literally
|
|
|
|
|
typing a python list `[tuple, tuple, tuple, ...]` where you paste in the serialized
|
|
|
|
|
tuple-strings with commas. At some point it's probably easier to do this in code though ...
|
|
|
|
|
|
|
|
|
|
### Linking Accounts and Characters
|
|
|
|
|
|
|
|
|
|
In `MULTISESSION_MODE` 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:
|
|
|
|
|
|
|
|
|
|
1. First create the complete Account in the admin.
|
|
|
|
|
2. Next, create the Object (usually of `Character` typeclass) and name it the same
|
|
|
|
|
as the Account. It also needs a command-set. The default CharacterCmdset is a good bet.
|
|
|
|
|
3. In the `Puppeting Account` field, select the Account.
|
|
|
|
|
4. Make sure to save everything.
|
|
|
|
|
5. Click the `Link to Account` 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):
|
|
|
|
|
- Set `account.db._last_puppet` to the Character.
|
|
|
|
|
- Add Character to `account.db._playabel_characters` list.
|
|
|
|
|
- Add/extend the `puppet:` lock on the Character to include `puppet:pid(<Character.id>)`
|
|
|
|
|
|
|
|
|
|
### Building with the Admin
|
|
|
|
|
|
|
|
|
|
It's possible (if probably not very practical at scale) to build and describe
|
|
|
|
|
rooms in the Admin.
|
|
|
|
|
|
|
|
|
|
1. Create an `Object` of a Room-typeclass with a suitable room-name.
|
|
|
|
|
2. Set an Attribute 'desc' on the room - the value of this Attribute is the
|
|
|
|
|
room's description.
|
|
|
|
|
3. Add `Tags` of `type` 'alias' to add room-aliases (no type for regular tags)
|
|
|
|
|
|
|
|
|
|
Exits:
|
|
|
|
|
|
|
|
|
|
1. Exits are `Objects` of an `Exit` typeclass, so create one.
|
|
|
|
|
2. The exit has `Location` of the room you just created.
|
|
|
|
|
3. Set `Destination` set to where the exit leads to.
|
|
|
|
|
4. Set a 'desc' Attribute, this is shown if someone looks at the exit.
|
|
|
|
|
5. `Tags` of `type` 'alias' are alternative names users can use to go through
|
|
|
|
|
this exit.
|
|
|
|
|
|
|
|
|
|
## Grant others access to the admin
|
|
|
|
|
|
|
|
|
|
The access to the admin is controlled by the `Staff status` 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Only Superusers can change the `Superuser status` flag, and grant new
|
|
|
|
|
permissions to accounts. The superuser is the only permission level that is
|
|
|
|
|
also relevant in-game. `User Permissions` and `Groups` found on the `Account`
|
|
|
|
|
admin page _only_ affects the admin - they have no connection to the in-game
|
2021-10-21 21:04:14 +02:00
|
|
|
[Permissions](./Permissions.md) (Player, Builder, Admin etc).
|
2021-05-23 00:18:27 +02:00
|
|
|
|
|
|
|
|
For a staffer with `Staff status` 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 `Can delete Account` permission, for example.
|
|
|
|
|
|
2021-10-21 21:04:14 +02:00
|
|
|
```{important}
|
2021-05-23 00:18:27 +02:00
|
|
|
|
|
|
|
|
If you grant staff-status and permissions to an Account and they still cannot
|
|
|
|
|
access the admin's content, try reloading the server.
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
2021-10-21 21:04:14 +02:00
|
|
|
```{warning}
|
2021-05-23 00:18:27 +02:00
|
|
|
|
|
|
|
|
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 ...
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## Customizing the web admin
|
|
|
|
|
|
2021-10-21 21:04:14 +02:00
|
|
|
Customizing the admin is a big topic and something beyond the scope of this
|
2021-05-23 00:18:27 +02:00
|
|
|
documentation. See the [official Django docs](https://docs.djangoproject.com/en/3.2/ref/contrib/admin/) for
|
2021-10-21 21:04:14 +02:00
|
|
|
the details. This is just a brief summary.
|
2021-05-23 00:18:27 +02:00
|
|
|
|
2021-10-21 21:04:14 +02:00
|
|
|
See the [Website](./Website.md) page for an overview of the components going into
|
2021-05-23 00:18:27 +02:00
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Admin templates are found in `evennia/web/templates/admin/` 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
|
2021-10-21 21:04:14 +02:00
|
|
|
(`django/contrib/admin/templates/`). So if you wanted to override one you'd have
|
2021-05-23 00:18:27 +02:00
|
|
|
to copy it from _there_ into your `mygame/templates/admin/` folder. Same is true
|
|
|
|
|
for CSS files.
|
|
|
|
|
|
|
|
|
|
The admin site's backend code (the views) is found in `evennia/web/admin/`. It
|
|
|
|
|
is organized into `admin`-classes, like `ObjectAdmin`, `AccountAdmin` etc.
|
|
|
|
|
These automatically use the underlying database models to generate useful views
|
2021-10-21 21:04:14 +02:00
|
|
|
for us without us havint go code the forms etc ourselves.
|
2021-05-23 00:18:27 +02:00
|
|
|
|
|
|
|
|
The top level `AdminSite` (the admin configuration referenced in django docs)
|
|
|
|
|
is found in `evennia/web/utils/adminsite.py`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Change the title of the admin
|
|
|
|
|
|
2021-10-21 21:04:14 +02:00
|
|
|
By default the admin's title is `Evennia web admin`. To change this, add the
|
2021-05-23 00:18:27 +02:00
|
|
|
following to your `mygame/web/urls.py`:
|
|
|
|
|
|
|
|
|
|
```python
|
|
|
|
|
# in mygame/web/urls.py
|
|
|
|
|
|
|
|
|
|
# ...
|
|
|
|
|
|
|
|
|
|
from django.conf.admin import site
|
|
|
|
|
|
|
|
|
|
#...
|
|
|
|
|
|
|
|
|
|
site.site_header = "My great game admin"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Reload the server and the admin's title header will have changed.
|