jazzband/django-admin2

Extendable, adaptable rewrite of django.contrib.admin

django-admin2's Issues

utiils.get_admin2s() fails on imports

This is taken from django.contrib.admin.init.py and https://github.com/pydanny/django-mongonaut/blob/master/mongonaut/mixins.py#L54.

It works in those places but on my test project it fails.

Copy/edit contributor documentation from OpenComparison

This: https://github.com/opencomparison/opencomparison/blob/master/docs/contributing.rst

Needs to be brought into our documentation directory.

Build is failing because of 2.6 support

We should drop 2.6 from travis since we don't support it.

See what ideas you can steal from django-dashbuilder

I started working on https://github.com/AndrewIngram/django-dashbuilder a while back. I didn't get that much done, but the basics of model editing is in place. The key thing that's missing is permissions. There might be some ideas or solutions you can steal.

Stub out tests!

Convert modeladmin to be 'model_admin'

We have a mix of modeladmin and model_admin. We really need to be consistent.

Generate test coverage reports

Get admin2.views.ModelDeketeView functioning

Copy/edit contributor documentation from OpenComparison

This: https://github.com/opencomparison/opencomparison/blob/master/docs/contributing.rst

Needs to be brought into our documentation directory.

model_list.html UI cleanup

should function more like...

(This issue doesn't include the header -- that's a separate ticket)

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.

Implement Sphinx for docs

• Index needs to include the contributing.rst file.
• See https://github.com/opencomparison/opencomparison for inspiration. DON'T COPY/PASTE!

Setup Continuous Integration

• Travis CI
• Add PyPI badges
• Add Github badge

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

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

Implement action dropdown in ModelListView

Stubbed out the UI quickly to roughly match the existing Django admin:

Get admin2.views.IndexView functioning

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.

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)

Stub out UI for admin index page

The old admin looks like this:

We should flesh this out to function similarly:

Support for inlines

Just like the old admin. I've got a branch with this implemented, I just need to get the formset rendering working in a readable fashion. Putting this here so you know it's being worked on

https://github.com/AndrewIngram/django-admin2/tree/inline-formsets

base.html needs a header with username and change password/log out links

Right now there is no header. It needs:

Change password page

Get admin2.views.ModelDetailView functioning

model_edit_form.html should have the same layout as in the old admin

should look more like this:

Login and Logout page

Theme guide

Implement test runner

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.

I18n in templates

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

Create example project to visually test against

We need something simple. It should have:

• 2 apps
• Each app needs 2 Models with one of each field type

Implement RESTFUL API

• Use django-rest-framework 2.3.3
• Create/Read/Update/Delete

Fix URLs in HTML theme to use proper {% url %} tag

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.

Views method: get_form_class()

• For add/edit model views
• Needs to create a ModelView with the correct models.Model.Meta.model attribute assigned

Default theme date/time widgets

Out of the box it would be nice if these were displayed with attractive bootstrap widgets

Model add page: Implement save options

On the create model page, implement the 'Save and add another', 'Save and continue editing', and 'Save' options from the original admin.

Add floppy-forms dependency

As per @pydanny's request.

I'll take this since it's related to #72, which I'm working on now.

Add django-rest-framework powered API

Make runserver.sh properly executable

runserver.sh needs a shebang line.

Delete confirmation form UI improvements

Get admin2.views.ModelEditFormView functioning

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

Make model_list.html look more like admin list view

http://127.0.0.1:8000/admin2/blog/post/ should look more like http://127.0.0.1:8000/admin/blog/post/, except with Bootstrap components

Document Model._meta for public use

• Document Model._meta
• Get that documentation at some point in the future into django core documentation

Get admin2.views.ModelListView functioning

Fix readthedocs.org post-commit hook

My docs update didn't show up on http://django-admin2.readthedocs.org/en/latest/ - please update.

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?

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