Update adminsite for better config

This commit is contained in:
Griatch 2021-05-20 09:45:14 +02:00
parent 68451419b4
commit 14968e4b42
9 changed files with 69 additions and 17 deletions

View file

@ -956,7 +956,6 @@ INSTALLED_APPS = [
"django.contrib.auth",
"django.contrib.contenttypes",
"django.contrib.sessions",
"django.contrib.admin",
"django.contrib.admindocs",
"django.contrib.flatpages",
"django.contrib.sites",
@ -973,7 +972,8 @@ INSTALLED_APPS = [
"evennia.comms",
"evennia.help",
"evennia.scripts",
"evennia.web"
"evennia.web",
"evennia.web.utils.adminsite.EvenniaAdminApp", # replaces django.contrib.admin
]
# The user profile extends the User object with more functionality;
# This should usually not be changed.

View file

@ -248,6 +248,7 @@ class AccountAdmin(BaseUserAdmin):
add_form = AccountCreationForm
inlines = [AccountTagInline, AccountAttributeInline]
readonly_fields = ["db_date_created", "serialized_string"]
view_on_site = False
fieldsets = (
(
None,

View file

@ -42,6 +42,7 @@ class HelpEntryAdmin(admin.ModelAdmin):
save_as = True
save_on_top = True
list_select_related = True
view_on_site = False
form = HelpEntryForm
fieldsets = (

View file

@ -146,6 +146,7 @@ class ObjectAdmin(admin.ModelAdmin):
save_as = True
save_on_top = True
list_select_related = True
view_on_site = False
list_filter = ("db_typeclass_path",)
# editing fields setup

View file

@ -99,6 +99,7 @@ class ScriptAdmin(admin.ModelAdmin):
save_as = True
save_on_top = True
list_select_related = True
view_on_site = False
raw_id_fields = ("db_obj",)
fieldsets = (

View file

@ -218,6 +218,7 @@ class TagAdmin(admin.ModelAdmin):
fields = ("db_key", "db_category", "db_tagtype", "db_model", "db_data")
list_filter = ("db_tagtype", "db_category", "db_model")
form = TagForm
view_on_site = False
fieldsets = (
(

View file

@ -18,8 +18,6 @@ urlpatterns = [
url(r"/doc/", include("django.contrib.admindocs.urls")),
]
admin.site.site_header = "Evennia web admin"
if settings.EVENNIA_ADMIN:
urlpatterns += [

View file

@ -18,8 +18,9 @@
<p class="card-text">
<h4><a href="{% url "admin:accounts_accountdb_changelist" %}">Accounts</a></h4>
Accounts can have several characters under them. A user's login and
password information can be changed here.
Accounts represent an out-of-character player and stores
configurations and password. An account can control/puppet one or
more in-game Objects (usually Characters).
</p>
<p class="card-text">
@ -37,14 +38,24 @@
<p class="card-text">
<h4><a href="{% url "admin:comms_channeldb_changelist" %}">Channels</a></h4>
Channels are used to redirect and organize player in-game communications.
Channels are used for mass communication, chat-room style. The
channel object holds subscriptions, options and access. The
communications themselves are logged to disk.
</p>
<p class="card-text">
<h4><a href="{% url "admin:comms_msg_changelist" %}">Msgs</a></h4>
Messages represent a piece of database-base saved communication
between sender(s) and receiver(s). By default they are used by
page/tell but can be used as building blocks for custom in-game
communication systems.
</p>
<p class="card-text">
<h4><a href="{% url "admin:help_helpentry_changelist" %}">Help Topics</a></h4>
Add help database help-entries here. Note that command-auto-help and
file-based help entries (added via FILEHELP_MODULES) are not visible
here.
Database-based Help entries like these can also be added from
in-game. Note that command-auto-help and file-based help entries
(added via FILEHELP_MODULES) cannot be modified or viewed from here.
</p>
<p class="card-text">
@ -56,11 +67,12 @@
<p class="card-text">
<h4><a href="{% url "admin:server_serverconfig_changelist" %}">ServerConfig</a></h4>
These are constants saved by the running server. While maybe interesting for
debugging, you should usually not modify these manually unless you
<i>really</i> know what you are doing. For example, the
<i>BASE_*_TYPECLASS</i> fields are stored in order to auto-update
when their setting changes; they must <i>not</i> be changed manually here.
ServerConfigs store variables set by the running server. While possibly
interesting for debugging, you should usually not modify these
manually unless you <i>really</i> know what you are doing. For
example, the <i>BASE_*_TYPECLASS</i> fields are stored in order to
auto-update when their setting changes; they must <i>not</i> be
changed manually here.
</p>
<hr />
@ -78,9 +90,9 @@
</p>
<p class="card-text">
<h4><a href="{% url "admin:flatpages_flatpage_changelist" %}">Pages</a></h4>
<h4><a href="{% url "admin:flatpages_flatpage_changelist" %}">Flat Pages</a></h4>
Create, edit and publish new web pages without needing to know how to
code. Select the domain specified by <strong>SITE_ID</strong> above.
code. Make sure to assign to a domain created above.
</p>
<p class="card-text">

View file

@ -0,0 +1,37 @@
"""
Custom Evennia admin-site, for better customization of the admin-site
as a whole.
This must be located outside of the admin/ folder because it must be imported
before any of the app-data (which in turn must be imported in the `__init__.py`
of that folder for Django to find them).
"""
from django.contrib.admin import apps
from django.contrib import admin
class EvenniaAdminApp(apps.AdminConfig):
"""
This is imported in INSTALLED_APPS instead of django.contrib.admin.
"""
default_site = 'evennia.web.utils.adminsite.EvenniaAdminSite'
class EvenniaAdminSite(admin.AdminSite):
"""
The main admin site root (replacing the default from Django). When doing
admin.register in the admin/ folder, this is what is being registered to.
"""
site_header = "Evennia web admin"
app_order = ["accounts", "objects", "scripts", "comms", "help",
"typeclasses", "server", "sites", "flatpages", "auth"]
def get_app_list(self, request):
app_list = super().get_app_list(request)
app_mapping = {app["app_label"]: app for app in app_list}
return [app_mapping.get(app_label) for app_label in self.app_order]