Thanks for the reply! The main thing I'm looking for is the ability to create more granular permissions. For example, I want only the person who creates an instance of something (plus a few admins) the be able to modify that instance. I talk about working "outside" the admin interface because my understanding from other threads I've read is that the admin is designed on the assumption that everyone either has admin privileges or doesn't on a per-class (as opposed to per-object) basis, and if you want more than that you're going to have to build your own editing interface.
Of course, what I'd love to hear is that I have this all wrong and there's an easy way to implement the concept of object ownership, custom permissions, etc in the existing admin interface. I guess subclassing AdminSite could be a start to this, but at least at first glanceI don't see anything in the docs about replacing or extending the access control mechanism. Anyone have advice along those lines? Thanks again! --Brad On Wednesday, November 20, 2013 5:32:30 PM UTC-5, Gonzalo Delgado wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > El 20/11/13 12:54, Brad Smith escribi�: > > Based on other threads I've read here, it seems that the > > conventional wisdom is that the admin interface is only for > > low-level access to the database, and isn't designed for anything > > "fancy", like users with different levels of administrative rights > > within an app, etc. Ok, I get that, but if I may grasp at some > > straws briefly I'd like to ask one follow-up that I haven't seen > > answered elsewhere: my app has a bunch of objects with complicated > > relationships for which I've devised a reasonably pretty and > > intuitive editing interface using Django's admin and Grappelli. > > Since this took a nontrivial amount of effort, I wanted to ask here > > if there are any tricks I should know about for re-using *any* > > views, inlines, etc from that admin interface in a more integrated > > editing interface with granular access controls, or do I just need > > to suck it up and rewrite everything from scratch using regular > > Django forms? > > The django admin code is very extensible and re-usable. The > documentation may not stress this enough, but it is possible to do > virtually anything you want with it. > > If I'm understanding your "outside" of the admin concept correctly, > what you want to do is extend the AdminSite[0] class (or maybe not > even that, just create a new instance) and attach the ModelAdmins you > want to it. I think you can even use autodiscover with a custom > AdminSite instance too if you need to have all models from > settings.INSTALLED_APPS attached to it. > > > [0] > https://docs.djangoproject.com/en/1.6/ref/contrib/admin/#adminsite-objects<https://www.google.com/url?q=https%3A%2F%2Fdocs.djangoproject.com%2Fen%2F1.6%2Fref%2Fcontrib%2Fadmin%2F%23adminsite-objects&sa=D&sntz=1&usg=AFQjCNHS1o9zmTuOBtsRtLct8Erv3F29KQ> > > > - -- > Gonzalo Delgado > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (Darwin) > Comment: Using GnuPG with Thunderbird - > http://www.enigmail.net/<http://www.google.com/url?q=http%3A%2F%2Fwww.enigmail.net%2F&sa=D&sntz=1&usg=AFQjCNEmzvPO3jS2yzcUMn8rNiYnCtPc-g> > > > iF4EAREIAAYFAlKNOH4ACgkQzbfdFL5JoUlCVQD6A1TUqYfKbgBDITrpvFblkQfo > nrVMCxnxSPIiREHgJaMBAKTR2auknxE6sX5s62B0j8eiH+AJB1EG1+AxeXoVHlGX > =kthG > -----END PGP SIGNATURE----- > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4bd041e0-2e4c-449c-9da8-2260c3af66f4%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
