add view_permission

[Ric]

i've been thinking about a new django admin feature, that could be
backward implemented

it's about adding a view permission for models

so we can have

1.change_permission
2.delete_permission
3.add_permission
and
4.view_permission

in the changelist_view view_permission allow user to see the
changelist, but user still need a change_permission to use the
list_editable.
in the change_view, having a view_permission allow to see the object,
but the method get_read_only_fields returns all the fields.

in every case a POST request raise a PermissionDenied if the user do
not have a change_permission, but allows GET request if user got a
view_permission

view_permission could be added on the next syncdb...

[Bradley Ayers]

I would benefit from this. With administration systems I build with Django I generally have to add my own 'view_foo' permission to each model. +1

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> 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.
>

[Ric]

yes i would use it too, because i've got a lot of models with a view
permission to the final user but with no change permission.

it could be archived with backward compatibility, because by default a
user has got no view permission
view permission can be added with a syncdb, and user must add them
from the admin panel

don't see backward issue, it would be a nice feature.

[Aymeric Augustin]

Hi Ric,

This feature request is quite common, and it's tracked here: https://code.djangoproject.com/ticket/8936

A few people talked to me since I wrote the GSoC project description linked in comment #5, but I don't think anyone is actively working on this.

Since we deprecated databrowse, the problem is much simpler than what I described. It's probably still more complicated than what a patch can handle.

If you want to work on this ticket, I suggest to:
a) read the contributing guide in the docs (if you haven't yet),
b) review related discussions on this mailing list, and search for related tickets in Trac,
c) post a more detailed proposal here,
d) fork the bitbucket or github mirror and work on your clone,
e) track your progress by commenting on the ticket or on the mailing list.

Be aware that this isn't an easy ticket — you may prefer to start with smaller issues and tackle this when you're more at ease with our development process.

Best regards,

--
Aymeric Augustin.

[Ric]

ok i can give a try...

maybe it's difficult, not to much. i have to see inline models, and
give the right behavior....

so from github i can fork django 1.3.1, but actually i'm working with
the latest version.

should i fork the lastest?

On 16 Nov, 20:21, Aymeric Augustin

[Ric]

at a first look, the big file to patch is django.contrib.admin.options

i need also to add a method to django.db.models.options

def get_view_permission(self):
return 'view_%s' % self.object_name.lower()

so maybe it's better to work only on options.py and make a .diff,
right?

[Aymeric Augustin]

Hi Ric,

I've noticed that you're posting a lot on this mailing list. Please remember that each email sent here is broadcasted to around 7000 people, each of whom will need a few seconds to decide if it's interesting.

You're expected to do some research and to structure your thoughts and questions before posting. From my own experience, it's unusual to write an email for django-developers in less than an hour, and it can even take several days. "Stream of thought" messages aren't appropriate; if you want to chat, please join the #django-dev on FreeNode.

Thanks for your understanding!

--
Aymeric Augustin.

[Ric]

fine i'll keep in mind.

On 16 Nov, 22:17, Aymeric Augustin

[Ric]

ok this is my last message, i swear!

i've created a new options.py file and a .diff, and i've attached it
to the ticket you send to me.

----

i've tested it and it works, it's pretty basic and there is more work
to do.

what i've done is to add a method has_view_permission, and check a
view permission in every view

i also created a get_list_editable, and i add in get_list_editable and
in get_readonly_fields a check, and it returns original read_only and
list_editable only if user has got a change_pemission

i also raise a permission error every time there is a post request and

user do not have a change_permission

a also ask for view_permission in history_view.

todo:

fix inlines fix submit_row

add a opts.has_view_permission()