Permissions need to be granular

[pydanny]

Permissions need to be granular

[gregmuellegger]

As discussed the logic for this will go into a permissions object that will live as an attribute on the ModelAdmin2.

[gregmuellegger]

Here is my current approach to refactoring the permissions:
gregmuellegger/django-admin2@twoscoops:develop...permission-refactoring

I think its very elegant to have the permission classes on the views, which makes permission checking extremly modular (example: gregmuellegger/django-admin2@twoscoops:develop...permission-refactoring#L2R60)

However there is no way yet to pass has_edit_permission etc into the template. However this will not reliably possible without having access to the model_admin from the view. Because only then we can fulfill the following usecase:

• User access the edit page
• The edit page contains a link to the delete page
• The delete link should only be visible if the user has the permission to delete the current object
• This means the edit page needs access to the permission handling of the delete view.

So we MUST have the delete view in the edit view to make this work... So thats another reason to just pass in the model_admin into the view -- see #99 for more.

[gregmuellegger]

I pushed my recent changes here: gregmuellegger/django-admin2@twoscoops:develop...permission-refactoring

There is a working implementation of permission checking (also works from the templates) that actually queries the responsible view if the user has the particular permission. This means if in the template {{ permissions.has_change_permission }} is used, the permission machinery will find its way to the update_view of the currently active model admin and will ask this view if the user really has the permission.

That way we can totally keep the permission handling in the views, users can easily extend its behaviour by only subclassing the view.

I think the code is very clean and commented out. However it is missing a bit of documentation to show the bigger picture. That will be my next part of work on the permission refactoring.

[pydanny]

Closing this as @gregmuellegger's documentation closes this ticket out.