GithubHelp home page GithubHelp logo

jazzband / django-admin2 Goto Github PK

View Code? Open in Web Editor NEW
1.2K 1.2K 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 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

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

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

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

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

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

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.

I18n in templates

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

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.

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.

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.