view permission for contrib.admin
gert
that are only allowed to ADD news items and higher level admins that
can CHANGE/DELETE them.
Without a view permission it is not possible to do this, you have to
give CHANGE rights to everybody (They must be able to see the list of
news items to know what they have already added)
Searching through the tickets I see very simple patches to accomplish
this that are declined because their out of scope.
I am a great believer in stopping feature creep dead in its tracks,
but surely a view permission is within the scope of even the simplest
admin application?
Your thoughts on this?
koos
flexability to Django.
Every permission system I can think of has a concept of view/read
only. I come from a Zope/Plone background and their permission system
is without a doubt one of the mayor reasons for their rapid uptake.
(Maybe even worth looking at Object/Local permissions in future)
Ludvig Ericson
> Your thoughts on this?
The Django book, for example, clearly states that the admin is for
administrators. Nothing less.
- Ludvig
Yuri Baburov
1) i'd like to have solution to allow my users to see their objects
with admin interface.
2) i'd like to have this built-in because
a) there's no simple way to do this manually without patching django,
b) there's no such solution ready and because
c) such solution implementation is going to change together with
admin backend changes.
3) also that's why i'd like to merge databrowse app and admin app.
4) i don't want to recreate full admin app from scratch to make my
users happy with sort of admin interface!
i'd like to volunteer on this if core devs agree with these features.
also we have a lot of work done already:
readonly widgets, databrowse app, and admin app :)
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
gert
need a VIEW permission.
But if you have 10 junior journalists, 3 senior journalists and an
editor it is slightly different. They are all administrators but not
all of them should have CHANGE permissions, some must just have ADD
permissions.
The issue is that neither an ADD nor a DELETE works properly unless
you have CHANGE as well. If we have a VIEW it would release the
dependency on the CHANGE permission.
To summarise currently the only usable scenarios are:
1) Some administrators can CHANGE and ADD
2) Some administrators can CHANGE and DELETE
If we had VIEW it would become:
1) Some administrators can ADD
2) Some administrators can CHANGE
3) Some administrators can DELETE
Which was definitely what was intended on day one when the CHANGE,
ADD, DELETE permissions were created.
- Gert
Collin Grady
> Which was definitely what was intended on day one when the CHANGE,
> ADD, DELETE permissions were created.
Says you.
Admin is for admins. Not limited users.
Write your own views.
--
Collin Grady
christian schilling
Admin is for admins. Not limited users.
then why does it have permissions at all?
Jacob Kaplan-Moss
tone here is deteriorating and that's not okay. Keep things
professional, please.
To get back to the original question, you can do this right now with a
bit of custom admin code. Take a look at
``ModelAdmin.has_change_permission`` -- you can override this method
to control exactly what the definition of "can change" is for a
particular object. Since this object gets passed ``request``, you can
differentiate between changelist requests and object change requests.
Alternately, your ``ModelAdmin`` subclass can extend the
``change_view`` or ``changelist_view`` methods directly and influence
their behavior.
gert, if you've got a specific suggestion for a hook to add to
``ModelAdmin`` to make this kind of use easier feel free to float it.
But please first try it my way and let me know why what's already
there won't work.
Jacob
christian schilling
To get back to the original question, you can do this right now with a
bit of custom admin code. Take a look at
``ModelAdmin.has_change_permission`` -- you can override this method
to control exactly what the definition of "can change" is for a
particular object. Since this object gets passed ``request``, you can
differentiate between changelist requests and object change requests.
Alternately, your ``ModelAdmin`` subclass can extend the
``change_view`` or ``changelist_view`` methods directly and influence
their behavior.
mybe changelist views should not check permissions at all, by default.
i ran in this when i wanted to use raw_id_admin and the users got "permission denied"
when they clicked on the magnification glass of the widget.
i solved this, as you said, by using a ModelAdmin subclass, and from what i have seen and done so
far it looks like all fancy permissin stuff i can think of can be done nicely this way, witch is great.
But things like this quickly lead to a situation where you want to use your own subclass of ModelAdmin
on _all_ models in the project (including User, Group, etc.) so my suggestion would be to figure out
a clean way to set a global custom admin class that all admin classes use as a base class, without needing
to change all admin.py files in the apps.
Jacob Kaplan-Moss
<init...@googlemail.com> wrote:
> mybe changelist views should not check permissions at all, by default.
If you think about this a bit you'll realize why this is a very, very
bad idea. I can think of at least three reasons.
> i solved this, as you said, by using a ModelAdmin subclass, and from what i
> have seen and done so
> far it looks like all fancy permissin stuff i can think of can be done
> nicely this way, witch is great.
Good to hear. The admin should *not* be complicated by default, but it
*should* be possible for you to add your own complexity if you need
it. So suggestions to change the default behavior are likely to be
viewed with skepticism, but suggestions for new hooks are probably
going to be accepted enthusiastically.
> But things like this quickly lead to a situation where you want to use your
> own subclass of ModelAdmin
> on _all_ models in the project (including User, Group, etc.)
I agree that this should be easier. Currently, if you stop using
``admin.autodiscover()`` you can register your own ``ModelAdmin`` for
any of the built-in classes (since the defaults won't get loaded).
However, this means you have re-invent admin class discovery, which is
sorta a pain.
I'd love to see suggestions about how we could make overriding admin
options for external models easier -- got any bright ideas?
Jacob
gert
problem implementing it like that. I have to go that route no matter
what the outcome of this discussion because it must be done in a
couple of days :)
I raised the view permission issue primarily because:
1) On a technical level there is a design flaw in the fact that the
ADD and DELETE permissions depend on the CHANGE permission.
2) On a non-technical level I absolutely love Django and I would love
to see it become the "next big thing". But to cater for tomorrows web
application requirements the admin needs a bit more.
It used to be just front-ends, then back-ends came along and changed
the world. Now we are moving towards subscription services where users
don't just click and read, they now personalise settings, publish
content etc (all traditional admin tasks). There is a need for
something between a hardcore sysadmin and a "dumb" user.
An example; any web service with resellers - a reseller is nothing
more than a limited administrator. With the correct permissions you
can setup a complete reseller control panel by simple assigning
selective permissions to the reseller group - this will take not more
than 2 minutes. It can be done in other ways but then you make life
difficult for new adapters of Django. You can't override low level
methods after a week of getting into Django, but you can most
certainly assign permissions to groups.
I read all the tickets/discussions on this before I opened this one
and it seems like most of the arguments against it were a bit
emotional rather than technical.
> But things like this quickly lead to a situation where you want to use
> your own subclass of ModelAdmin on _all_ models in the project
going to surface in more and more projects. Lets get a solution for
this (whatever it is) and implement it in Django instead of everybody
implementing workarounds - afterall we all belive in DRY otherwise we
would be coding in ASP :)
Jacob Kaplan-Moss
> 1) On a technical level there is a design flaw in the fact that the
> ADD and DELETE permissions depend on the CHANGE permission.
Really, no, there's not. The fact that you disagree with the design
doesn't mean it's a "design flaw." Put it this way: I drive a very
small car. The fact that it can't hold as much cargo as a pickup truck
isn't a "flaw" -- it's just a different decision. We've decided that
the fundamental action in the admin is changing things and that
add/delete are spin-offs of that. It's not "wrong," just apparently
not what you'd expected. Sorry about that.
> 2) On a non-technical level I absolutely love Django and I would love
> to see it become the "next big thing".
"Just do this one thing and you'll be more popular" didn't end well
for me in high school, and it's not a good technical argument either.
Let's stick to the tech and leave the popularity contest out of it.
Jacob
gert
I can't argue about that add/delete is a form of change :)
> popularity contest
It is most certainly not that, it is about business and making money.
I have been in software development for 15 years now and on more than
one occasion we had to stop using a development tool because the
market changed and the tool didn't keep up. That means cross training
developers and losing a lot of skills when you do. I want Django to be
the tool we use for the long haul.
> how to do it
My suggestion is that the current permissions are handled fine, just
add an additional permission and use it in the changelists. Natural
progression would then be to add a "view" view (I will volunteer to
write the read-only widget that displays all field types). Am I
missing something?
christian schilling
On Thu, Dec 18, 2008 at 10:35 AM, christian schilling
<init...@googlemail.com> wrote:
> mybe changelist views should not check permissions at all, by default.
If you think about this a bit you'll realize why this is a very, very
bad idea. I can think of at least three reasons.
well i'm not sure what reasons you mean, but i think there is a real problem
because raw_id_admin uses the changelist view to let the user pick an object.
so in this case changlist views are used, without intent to actually change something.
an other option would be to somehow remove the dependency of the raw_id_admin
popup on the changelist, maybe by useing another view for that.
> i solved this, as you said, by using a ModelAdmin subclass, and from what i
> have seen and done so
> far it looks like all fancy permissin stuff i can think of can be done
> nicely this way, witch is great.
Good to hear. The admin should *not* be complicated by default, but it
*should* be possible for you to add your own complexity if you need
it. So suggestions to change the default behavior are likely to be
viewed with skepticism, but suggestions for new hooks are probably
going to be accepted enthusiastically.
for my work, but others may not need permissions at all.
as i said one thing i really like, is the fact that extensions like this can be implemented cleanly as a django-app
and there is no need to change django itself (like the row-level-permissions branch did in pre-newforms-admin days)
i case someone is intrested in this, i've put it on github:
http://github.com/initcrash/django-object-permissions/tree/master
I agree that this should be easier. Currently, if you stop using
> But things like this quickly lead to a situation where you want to use your
> own subclass of ModelAdmin
> on _all_ models in the project (including User, Group, etc.)
``admin.autodiscover()`` you can register your own ``ModelAdmin`` for
any of the built-in classes (since the defaults won't get loaded).
However, this means you have re-invent admin class discovery, which is
sorta a pain.
I'd love to see suggestions about how we could make overriding admin
options for external models easier -- got any bright ideas?
since you mention admin.autodiscover(), one idea would be to pass it a ModelAdmin subclass like
admin.autodiscover(baseclass=MyModeAdmin)
an other option would be something like admin.register_baseclass(MyModelAdmin)
and then make admin.register() use this instead of the default.
the ugly side of this is however, that in case admin.register is called like
admin.register(SomeModel,SomeModelAdmin) it would need to
combine MyModelAdmin wiith SomeModelAdmin (this applies to the first suggestion as well.
another way could be to introduce a method admin.get_base() and make the apps use
class SomeModelAdmin(admin.get_base()):
instead of
class SomeModelAdmin(admin.ModelAdmin):
the drawback here is of course: it changes the api (althougt not backward incompatible)
alex....@gmail.com
On Dec 18, 1:25 pm, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
>
remove the model admin and then register your own.
Yuri Baburov
<jacob.ka...@gmail.com> wrote:
>
> On Thu, Dec 18, 2008 at 11:38 AM, gert <ge...@ise.co.za> wrote:
>> 1) On a technical level there is a design flaw in the fact that the
>> ADD and DELETE permissions depend on the CHANGE permission.
>
> Really, no, there's not. The fact that you disagree with the design
> doesn't mean it's a "design flaw." Put it this way: I drive a very
> small car. The fact that it can't hold as much cargo as a pickup truck
> isn't a "flaw" -- it's just a different decision. We've decided that
> the fundamental action in the admin is changing things and that
> add/delete are spin-offs of that. It's not "wrong," just apparently
> not what you'd expected. Sorry about that.
Jacob, I understand your position very well.
You want to keep admin simple and easy for users to use and understand.
Adding "view" permission and maybe some other permissions is a typical
task if you want to customize admin interface. Right now most of
novice python and django developers can't do this properly.
Let's make this task simple, like you made changing objects simple with admin.
Writing documentation on how to make this, or adding this to django, whatever.
This is the first "request" from us "customizators".
Of course, you don't have to make this task simple yourself -- but
then please point us what we should do to make this easy with django.
Second is "readonly" data problem in admin.
It's also typical task on admin customization, and it's not easy for a
novice also.
Third is your point of view to admin customization at all.
I see you and some other people showing us position that admin is not
built for customization in mind, but it's possible to do that.
I have different position: let's make that easy.
Current hooks are not going to make that easy. They are workarounds by nature.
The result code is messy after such admin customization (if you need
to add more than one feature, of course).
The best solutions in this domain are not documented in one source.
So, let's think together, how we can make admin customization even
more easy that is now?
I'm also interested if you have a lot of experience customizing admin
interface in your recent projects. Was that hard? Was the code a mess
after that?
P.S. Other typical requests I implemented in different projects and
didn't feel it was easy either:
* Attribute change history,
* Unified non-admin changes history in admin interface,
* Readonly widgets.
* Multi-stage add (like you did on user add)
* Inline objects in add stage.
* New permissions like "Changeable by creators only", "Changeable if
assigned to user".
* Different types of fields visible to different users in change page.
Sometimes I thinking maybe it was faster to write my own site
administration framework instead of customizing existing one... But a
thought that admin interface is already written, is powerful and is so
simple to begin with, always stopped me from this.
Jonas Obrist
my use case was for DjangoCon Europe where admins were allowed to see ticket info, but only "super admins" were allowed to change them as changes likely had an impact on payments etc too (read PayPal). The solution was that everyone had change/add permission, only super admins had delete perms. Further I changed get_readonly_fields to mark everything read-only for non-super admins. That was perfectly doable but was needlessly complicated in my opinion.
it could be solved in a third party app but I'd argue having this option by default would be beneficial to lots of users.
just my two cents...
Jonas
Marc Aymerich
the worst thing of implementing full support for view permissions is
that you have to **copy&paste all the change_view and
changelist_view** just for changing one conditional:
if not self.has_change_permission(request, obj):
raise PermissionDenied
replace with:
# change_view
if not self.has_view_permission(request, obj):
raise PermissionDenied
if request.method == 'POST' and not self.has_change_permission(request, obj):
raise PermissionDenied
# changelist_view
if not self.has_view_permission(request, None):
raise PermissionDenied
So for me this is not one of those situations that you can say: oh if
you want it, just implement it on your own. Because doing so it's just
a mess.
br.
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/fPvFtNkTax4J.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
--
Marc