Restricting add in the admin

[Peter]

I have two models in my app - one is standard in that it allows
changing existing records/instances and adding new ones. But the other
- actually a FrontPage model - does not permit adding another
instance. There are ways to do this but I am wondering if there is a
standard way as it seems a common use-case. I am still pretty new to
Django so excuse if this is a FAQ.

-- Peter

[James PIC]

You could make such a check and deny the saving of a new FrontPage
object by overloading the save() method of class FrontPage.
Source in trunk: django/db/models/base.py.

Regards, James.

[Peter]

>
> You could make such a check and deny the saving of a new FrontPage
> object by overloading the save() method of class FrontPage.
> Source in trunk: django/db/models/base.py.
>
> Regards, James.

Thanks James.

Yes - I see that would work - but it involves coding and I was looking
for a more 'declarative'
way.

After posting I thought of the following (WHY is it always AFTER
posting??).

I'll give the user permission to change a FrontPage instance but not
delete or add one. The real admin user
will have just to avoid adding / deleting but this user ain't used
(much). In the FrontPage view I can check
that the original view is being used (perhaps by looking for pk==1 or
something). The main thing is that this
switches off the admin template buttons 'x delete' '+add' etc.

What I was looking for was a global permission that could be set on a
model when it was defined which set
default permissions for 'staff' on the model (or even for superuser)
on that model.

Regards, Peter

[James PIC]

On 12/19/08, Peter <pe...@monicol.co.uk> wrote:
>
>
> >

> > You could make such a check and deny the saving of a new FrontPage
> > object by overloading the save() method of class FrontPage.
> > Source in trunk: django/db/models/base.py.
> >
> > Regards, James.
>
>
> Thanks James.
>
> Yes - I see that would work - but it involves coding and I was looking
> for a more 'declarative'
> way.

Why?
The really proper way to do that is to store the sole FrontPage model
in a json file, the file-system is better suited than a RDBMS to store
one single instance of a single structure IMHO.

> I'll give the user permission to change a FrontPage instance but not
> delete or add one. The real admin user
> will have just to avoid adding / deleting but this user ain't used
> (much). In the FrontPage view I can check
> that the original view is being used (perhaps by looking for pk==1 or
> something). The main thing is that this
> switches off the admin template buttons 'x delete' '+add' etc.

You might also overload default admin templates for FrontPage, but
permissions allow security.

> What I was looking for was a global permission that could be set on a
> model when it was defined which set
> default permissions for 'staff' on the model (or even for superuser)
> on that model.

Why not just create another group?

Don't forget to save your permissions in
yourapp/data/initial_data.json with the help of the dumpdata
management command, since it's consistence critical.

Regards, James.

[Peter]

>
> >  What I was looking for was a global permission that could be set on a
> >  model when it was defined which set
> >  default permissions for 'staff' on the model (or even for superuser)
> >  on that model.
>
> Why not just create another group?

Because being a singleton (and not removable) should be, I think, an
*attribute* of the
class/model not of a particular user or a group.

Cheers, Peter

[felix]

just a thought:

you might consider allowing multiple front page objects and having a way to select the current one.
this could come in handy to switch what is currently the front page (or to audition the new front page).

otherwise : create one using initial_data so that your application automatically creates it
and then set the add permissions to false for everybody.  you can only edit The One.
a super user could still add one, but don't set your client/end-user to super user.
check on save and throw an error if you like.

-fx

[Peter]

On Dec 20, 1:03 pm, felix <crucialfe...@gmail.com> wrote:
> just a thought:
>
> you might consider allowing multiple front page objects and having a way to
> select the current one.
> this could come in handy to switch what is currently the front page (or to
> audition the new front page).
>

Yes - perhaps add a Boolean field (not shown in the admin)
'is_active'

Thanks, Peter

[James PIC]

Very relevant, don't forgot to overload the save method to set
other is_active to 0!

Regards, James.

[Peter]

> Very relevant, don't forgot to overload the save method to set
> other is_active to 0!
>
> Regards, James.

Ah - yes that would seem a good idea :-).

P.