django管理界面美化_非人员用户的Django管理界面

django管理界面美化

A while back I had a Django application in which I needed registered users able to view, create, update and delete objects in my system. These objects were instances of only a subset of all the Django models.Model subclasses I had defined in the models.py file of my application.

前一段时间，我有一个Django应用程序，其中需要注册用户能够查看，创建，更新和删除系统中的对象。 这些对象只是所有Django models.Model子集的实例。我在应用程序的models.py文件中定义的models.Model子类。

You may find this problem very similar to what th Django Admin site solves for administrators: you register some models that are displayed, and then the admins can create/update/delete the objects in the system as needed. Cool, lets use the Django admin! We should only call admin.site.register() on those models we want users to be able to act on and we have a full CRUD interface over the models. However, there are some issues with this naive approach:

您可能会发现此问题与Django Admin网站为管理员解决的问题非常相似：您注册了一些显示的模型，然后管理员可以根据需要在系统中创建/更新/删除对象。 酷，让我们使用Django管理员！ 我们只应在希望用户能够执行操作的模型上调用admin.site.register()在模型上具有完整的CRUD接口。 但是，这种幼稚的方法存在一些问题：

• Only users flagged as staff members can login into the Django admin interface.
• We would like to maintain the real administrator’s ability to act on many more models, not just those over which we want the mere mortal users to have CRUD capabilities. By not registering for the admin view, the real admin cannot create, view or delete content he might need to.

• 只有标记为职员的用户才能登录Django管理界面。
• 我们希望维持真正的管理员处理更多模型的能力，而不仅仅是我们希望普通用户具有CRUD功能的模型。 通过不注册管理员视图，真实管理员无法创建，查看或删除他可能需要的内容。

So, should we copy every template and replicate the logic of the Django Admin interface? No need. Fortunately, we can have multiple admin sites functioning at the same time.

那么，我们应该复制每个模板并复制Django Admin界面的逻辑吗？ 没必要。 幸运的是，我们可以有多个管理网站 在同一时间运行。

The Django documentation explains that the default Admin site (django.contrib.admin.site) is actually just an instance of django.contrib.admin.sites.AdminSite. We can easily subclass AdminSite class to build new instances of the Django administration site, provided we give it a name different than “admin” when we instantiate it. So, having our own custom admin is as easy as having code like this in an admin.py file:

Django文档解释说，默认管理站点（ django.contrib.admin.site ）实际上只是django.contrib.admin.sites.AdminSite一个实例。 我们可以轻松地对AdminSite类进行子类化，以构建Django管理站点的新实例，只要在实例化时为其赋予与“ admin”不同的名称即可。 因此，拥有我们自己的自定义管理员就像在admin.py文件中拥有如下代码一样容易：

And in the urls.py:

并在urls.py中：

Unfortunately a problem still persists, since only staff members are allowed to login into our new UserAdmin site. For this, we inspect the django/contrib/admin/sites.py file and find all the checks for is_staff. We find only one match in the has_permission() function of the AdminSite class itself. So in our subclass, we override the function removing the check:

不幸的是，问题仍然存在，因为只允许工作人员登录我们的新UserAdmin网站。 为此，我们检查了django / contrib / admin / sites.py文件，并找到了is_staff所有检查is_staff 。 我们在AdminSite类本身的has_permission()函数中仅找到一个匹配项。 因此，在子类中，我们重写了删除检查的功能：

Done? Not yet. If you try it out you will see that non staff users still can’t login. Further inspection finds a login() function in the AdminSite class, and this chunk of code in it:

做完了吗 还没。 如果您尝试一下，将会看到非工作人员用户仍然无法登录。 进一步检查会在AdminSite类中找到一个login()函数，其中的AdminSite代码是：

So as we are not providing any custom login_form, it uses the default AdminAuthenticationForm which must contain the check for is_staff. Thanks to Django’s modular architecture it is very easy to just make our own login form and plug it in our UserAdmin. We just subclass AdminAuthenticationForm and provide our own clean() function, which works the same but avoids the check:

因此，由于我们没有提供任何自定义的login_form ，因此它使用默认的AdminAuthenticationForm ，其中必须包含对is_staff的检查。 得益于Django的模块化体系结构，只需创建我们自己的登录表单并将其插入到UserAdmin非常容易。 我们只是将AdminAuthenticationForm子类AdminAuthenticationForm并提供我们自己的clean()函数，该函数的作用相同，但避免了检查：

And we plug it in our UserAdmin class:

然后将其插入到UserAdmin类中：

(Note aside: with this knowledge we could even create a different admin site for Django’s superuser and regular staff members, just adding the is_superuser check to has_permission() ;))

（请注意：有了这些知识，我们甚至可以为Django的超级用户和正式员工创建一个不同的管理站点，只需将is_superuser检查添加到has_permission() ;）

Now we are done! We can login successfully into our brand new admin (or not so much) site for non staff users. There are a few gotchas, namely that some of the templates used by the admin site also contains an is_staff check in the template itself. For example in Django 1.3.1 line 26 of contrib/admin/templates/admin/base.html is:

现在我们完成了！ 对于非职员用户，我们可以成功登录我们全新的admin（或不多）网站。 有一些陷阱，即管理站点使用的某些模板在模板本身中也包含is_staff检查。 例如，在Django 1.3.1中，contrib / admin / templates / admin / base.html的第26行是：

{% if user.is_active and user.is_staff %}
{% if user.is_active and user.is_staff %}
 

翻译自: https://www.pybloggers.com/2012/06/a-django-administration-interface-for-non-staff-users/

django管理界面美化