GithubHelp home page GithubHelp logo

jazzband / django-admin2 Goto Github PK

View Code? Open in Web Editor NEW
1.2K 62.0 152.0 3.08 MB

Extendable, adaptable rewrite of django.contrib.admin

License: BSD 3-Clause "New" or "Revised" License

Python 77.91% HTML 14.61% CSS 2.09% JavaScript 0.87% Less 2.41% SCSS 2.10%

django-admin2's Introduction

django-admin2

Jazzband GitHub Actions Code coverage

One of the most useful parts of django.contrib.admin is the ability to configure various views that touch and alter data. django-admin2 is a complete rewrite of that library using modern Class-Based Views and enjoying a design focused on extendibility and adaptability. By starting over, we can avoid the legacy code and make it easier to write extensions and themes.

Full Documentation at: https://django-admin2.readthedocs.io/

Features

  • Rewrite of the Django Admin backend
  • Drop-in themes
  • Built-in RESTful API

Screenshots

Site administration Select user

Requirements

Installation

Use pip to install from PyPI:

pip install django-admin2

Add djadmin2 and rest_framework to your settings file:

INSTALLED_APPS = (
    ...
    'djadmin2',
    'rest_framework', # for the browsable API templates
    ...
)

Add setting for apps and the default theme in your settings file:

# In settings.py
INSTALLED_APPS += ('djadmin2.themes.djadmin2theme_bootstrap3',)
REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 10
}
ADMIN2_THEME_DIRECTORY = "djadmin2theme_bootstrap3"

Add djadmin2 urls to your URLconf:

# urls.py
from django.conf.urls import include

from djadmin2.site import djadmin2_site

djadmin2_site.autodiscover()

urlpatterns = [
  ...
  url(r'^admin2/', include(djadmin2_site.urls)),
]

How to write django-admin2 modules

# myapp/admin2.py
# Import your custom models
from django.contrib.auth.forms import UserCreationForm, UserChangeForm
from django.contrib.auth.models import User
from djadmin2.site import djadmin2_site
from djadmin2.types import ModelAdmin2

from .models import Post, Comment


class UserAdmin2(ModelAdmin2):
    # Replicates the traditional admin for django.contrib.auth.models.User
    create_form_class = UserCreationForm
    update_form_class = UserChangeForm


#  Register each model with the admin
djadmin2_site.register(Post)
djadmin2_site.register(Comment)
djadmin2_site.register(User, UserAdmin2)

Migrating from 0.6.x

  • The default theme has been updated to bootstrap3, be sure to replace your reference to the new one.
  • Django rest framework also include multiple pagination system, the only one supported now is the PageNumberPagination.

Therefore, your settings need to include this:

# In settings.py
INSTALLED_APPS += ('djadmin2.themes.djadmin2theme_bootstrap3',)
ADMIN2_THEME_DIRECTORY = "djadmin2theme_bootstrap3"

REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 10
}

The default admin2 site has move into djadmin2.site make sure your use the news djadmin2_site in your urls.py:

# urls.py
from django.conf.urls import include

from djadmin2.site import djadmin2_site

djadmin2_site.autodiscover()

urlpatterns = [
  ...
  url(r'^admin2/', include(djadmin2_site.urls)),
]

Migrating from 0.5.x

Themes are now defined explicitly, including the default theme. Therefore, your settings need to include this:

# In settings.py
INSTALLED_APPS += ('djadmin2.themes.djadmin2theme_default',)
ADMIN2_THEME_DIRECTORY = "djadmin2theme_default"

Drop-In Themes

The default theme is whatever bootstrap is most current. Specifically:

# In settings.py
INSTALLED_APPS += ('djadmin2.themes.djadmin2theme_bootstrap3',)
ADMIN2_THEME_DIRECTORY = "djadmin2theme_bootstrap3"

If you create a new theme, you define it thus:

# In settings.py
# Mythical theme! This does not exit... YET!
INSTALLED_APPS += ('djadmin2theme_foundation',)
ADMIN2_THEME_DIRECTORY = "djadmin2theme_foundation"

Code of Conduct

Everyone interacting in the django-admin2 project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the Jazzband Code of Conduct.

Follows Best Practices

This project follows best practices as espoused in Two Scoops of Django: Best Practices for Django 1.8.

django-admin2's People

Contributors

andrewingram avatar andrewsmedina avatar arthur-wsw avatar audreyfeldroy avatar auvipy avatar beezz avatar bentappin avatar bootandy avatar chrisjones-brack3t avatar chrislawlor avatar dbrgn avatar douglasmiranda avatar esoergel avatar galuszkak avatar gregmuellegger avatar ifosch avatar inglesp avatar jezdez avatar kennethlove avatar ludw avatar montiniz avatar notsqrt avatar powersurge360 avatar pydanny avatar raphaelkimmig avatar rivol avatar ryanbalfanz avatar the5fire avatar waustin avatar z4r avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

django-admin2's Issues

Permissions need to be granular

This either needs to be made to function, or documented so it's understandable how to implement the following use cases

Use Case 0: (Django default)

  • Admins have full control
  • Admins can assigned controls to Staff level users.
  • No one else can see anything

Use case 1:

  • I am an admin. I have full controls.
  • You are an authenticated or unauthenticated user. You are allowed to read data

Use case 2

  • I am an admin. I have full controls.
  • You are an authenticated user, you are allowed to read data.
  • You are an unauthenticated user, you are not allowed to see anything

Admin breadcrumb menu

We should probably implement breadcrumbs exactly as they are in the current admin (but with stock Bootstrap components)

screen shot 2013-05-19 at 10 03 05 am

I18n in templates

We should use i18n in all templates so we can translate it later on.

Implement default bootstrap theme

  • Using Bootstrap as provided by CDN, this must be a workable implementation of the HTML view.
  • Minimal JQuery!
  • base template
  • index template
  • form template
  • detail template

Design Decision Needed: have admin2.core.Admin2 subclass contrib.admin.sites.AdminSite

I've not been at the sprints, so this may well have been discussed already.

Wanting to contribute, I started looking at implementing the admin auth urls (login, logout, password change, etc.). As I worked, it became clear that I was duplicating a lot of functionality from the original AdminSite class from contrib.admin. The only added 'feature' was incorporating ADMIN2_THEME_DIRECTORY into the template path.

It seems to me that if Admin2 subclassed AdminSite, we'd get a good bit of functionality for free. AdminSite implements all of the auth urls, Admin2 would only have to override get_urls, and change all of the template names as class attributes.

At first glance, it seems as if we might also be able to re-use at least some of the permissions code from AdminSite as well.

I've written a quick spike which takes the approach outlined above. All tests pass, after only having to change the test that counts the number of admin urls.

Note I had to refactor the settings file into separate files, since having django-debug-toolbar in INSTALLED_APPS was breaking the admin login test (specifically, the redirect intercepts). Ideally, settings would be a package, but I didn't want to break existing environments that might rely on DJANGO_SETTINGS_MODULE=example.settings.

Layouts / fieldsets / simple ways to change the field order and layout

We should provide a simple way to rearrange/group fields in the admin without creating custom templates.
The current admin offers this functionality via fieldsets in a rather specific way.

We could look at how crispy form layouts does this stuff where you can go ahead and do stuff like this:

layout = Row(Span("name", "age"), Span("email", "phone"))

This would make it easy to produce nice form layouts without having to drop into the template
for simple modifications.

For more details see http://django-crispy-forms.readthedocs.org/en/d-0/layouts.html

Provide an easy way to change / extend menus

We need some way to specify which views are available for a certain admin.

It might make sense to have something like a get_menu_entries() method on the
admin instance that returns the urls + verbose names for all available views.
This would be used to build menus, dashboards and these kinds of things.

Also when extending the admin you could just add a new menu entry for additional custom views.

Potential state linkage between the view and the ModelAdmin2 object passed in the request

If the view, which is called by the urls generated by the ModelAdmin object and yet receives a reference to the ModelAdmin as passed in as_view() modifies the state of the ModelAdmin object, then everyone sees that new data.

This can be mitigated in three ways:

  1. Document the issue and encourage developers not to change state on the ModelAdmin2 object. (Potential for a catastrophic developer-user mistake but is the django.contrib.admin standard)
  2. Remove the passing of the ModelAdmin2 object (Will require major refactoring - @freakboy3742's preference).
  3. Make a copy of the object that does not allow for state changes (Is a bit tricky but not insurmountable, unfortunately has potential performance problems).

Occurs: models.ModelAdmin2.get_default_view_kwargs

Permissions functions in `models.py` need work

In models.py we define several methods for determining whether a user has permission on a view (eg has_view_permission). These methods don't offer very fine-grained control. Should we use the the has_perm method from contrib.auth as is done in the original admin in options.py?

Design goals - outline needed.

Right now there is no documentation outlining the design of the project.

Some questions that come to mind:

  • How do the admin views interact with the admin instance? Do they have access to an Admin2 instance? Do the views use the Admin2 instance for common tasks like getting a queryset?
  • How are related models handled with the desired registration scheme - are they still set up independently and added to the "main" Admin2 instance (inlines = [ ... ])?
  • Is the goal to closely follow the "old" admin with respect to configuration (admin.list_display_fields, ...)? Or would it be preferable to reduce the amount of configuration on the Admin2 class and push more of it onto the CBVs?
  • Is there a high level menu abstraction (like a get_menu_entries that returns all Entries for an Admin2 instance)?

...

If this kind of document already exists it would be great if it was added to the repo.

Put view logic into functions

  • Move logic in views into functions as much as possible
  • Add exception handling for when a model is not found for a view.

Support for legacy app models (e.g. contrib.auth models)

One way to provide support for commonly used django apps (like contrib.auth) would be to ship a simple package (admin2-legacy or something) that just tries to register those other apps with admin2.

  • django.contrib.auth
  • django.contrib.sites

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.