read only django admin

[zweb]

Is it possible to have a read only django admin, ie user cannot add,
delete or update. User can only view data.

or may be one user can be view only and other user has add/delete /
update as well in Django admin.

How to do that?

[James Bennett]

The Django administrative interface is there to allow administrative
users to administer data.

If you'd like a non-administrative interface to allow
non-administrative users to not administer data, you might want to
look into generic views.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[chefsmart]

> The Django administrative interface is there to allow administrative
> users to administer data.

But yes, you can do what you want if you use the permissions system
together with the groups system correctly. That is, create groups and
then assign whatever permissions you need to those groups. Then create
users and assign your users to the groups you created earlier.

Regards.

On Jan 29, 8:03 am, James Bennett <ubernost...@gmail.com> wrote:

[Kenneth Gonsalves]

On Friday 29 Jan 2010 10:01:15 am chefsmart wrote:
> > The Django administrative interface is there to allow administrative
> > users to administer data.
>
> But yes, you can do what you want if you use the permissions system
> together with the groups system correctly. That is, create groups and
> then assign whatever permissions you need to those groups. Then create
> users and assign your users to the groups you created earlier.
>

but as already mentioned it goes against the basic philosophy behind the admin
- admin is not for ordinary users who you do not trust to mess up the data.
--
regards
Kenneth Gonsalves
Senior Project Officer
NRC-FOSS
http://nrcfosshelpline.in/web/

[chefsmart]

>admin is not for ordinary users who you do not trust to mess up the data.

Whether you provide such functionality outside of the admin or inside
it, you are using the same django.contrib.auth, so "trust" is not the
reason why you cannot do what you want to do within
django.contrib.admin. If the permissions system cannot be "trusted",
then it shouldn't be part of the django release. In all likelihood,
the original poster zweb can do what he/she wants to do without
compromising the system.

Django developers wouldn't have relied on permissions in the admin
section if it weren't solid enough.

Regards.

[Mike Ramirez]

On Thursday 28 January 2010 21:04:15 chefsmart wrote:
> >admin is not for ordinary users who you do not trust to mess up the data.
>
> Whether you provide such functionality outside of the admin or inside
> it, you are using the same django.contrib.auth, so "trust" is not the
> reason why you cannot do what you want to do within
> django.contrib.admin. If the permissions system cannot be "trusted",
> then it shouldn't be part of the django release. In all likelihood,
> the original poster zweb can do what he/she wants to do without
> compromising the system.
>
> Django developers wouldn't have relied on permissions in the admin
> section if it weren't solid enough.
>

It's none of this, it's all design philosophies, everyone trying to exert
their own

Alot of people think the admin section is for admins, not arbitrary data
updates from users and provide generic crud views for users. Others think
users and admin should be able to do everything within the admin panel becaue
it's there. Some hardcore folks can say f**k the admin panel and build their
own from scratch, others may just do direct db inserts using some db tool
(like pgadmin3).

How it's done is upto the developer in question. But expect answers that say
"you're doing it wrong cause that's not how I do it." Because no one
understands that my choice may not be your choice.

*remembers first time I asked about the admin panel in irc and someone tried
to convince me the admin panel was for database administrators, not site
admins.*

Mike

--
A lawyer named Strange was shopping for a tombstone. After he had
made his selection, the stonecutter asked him what inscription he
would like on it. "Here lies an honest man and a lawyer," responded the
lawyer.
"Sorry, but I can't do that," replied the stonecutter. "In this
state, it's against the law to bury two people in the same grave. However,
I could put ``here lies an honest lawyer'', if that would be okay."
"But that won't let people know who it is" protested the lawyer.
"Certainly will," retorted the stonecutter. "people will read it
and exclaim, "That's Strange!"

[Ian]

Despite the pedantic admonishments offered by others, there are use
cases for readonly fields beyond primary keys. Metadata or implicit
data that really shouldn't be changed isn't a "trust" issue, it's
semantically different that application domain data. Anyway, I found
this code has some issues but the idea sound, see if it helps
http://bitbucket.org/stephrdev/django-readonlywidget/

[Alex Robbins]

It sounds like the databrowse[1] contrib app may be what you are
looking for. It is basically a read-only admin. You'll have to
register classes with it the same way you register with the admin, but
it might be nicer than trying to force the admin to be read-only.

Hope that helps,
Alex

[1] http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/

[aledr]

http://www.alextreme.org/drupal/?q=django-view-permissions-patch

Just read at bottom:

"Feel free to use the patch, but be warned: if users logging in to
your site really want to change something, they'll probably find a way
through."

--
[ ]'s
Aledr - Alexandre
"OpenSource Solutions for SmallBusiness Problems"