There is no need to implement the same CRUD over and over again with the help of generic views and signals. :)
https://docs.djangoproject.com/en/1.3/ref/class-based-views/ Mind you, I've only used these generic views in 1.2 and never yet took some time to learn the new class-based one. Although the class-based one seems much more flexible to implement a CRUD with very little work. Signals will help for when you do updates in the database, it can auto- fill information that should be set, such as the user saving the entry. https://docs.djangoproject.com/en/1.3/topics/signals/ A Django app that I think will help you realize this fine grained type of database layout would be django-guardian. This way you can set permissions and group assignments per row object. The admin interface can even be coded to respect it as well, for managers who need more fine grain controls to do edits at a low-level. You can use a signal to assign the user's group to the object they just created. Each company can be assigned a group, and the objects owned by that company can be assigned to their specific group. The users in that company can be part of the company/branch group. Django-guardian is very flexible and would be the easiest way(in my eyes) to implement this type of system you seek to make. https://github.com/lukaszb/django-guardian Read the docs for it here: http://packages.python.org/django-guardian/ Hope this helps. On Oct 20, 4:43 am, "zzart...@googlemail.com" <zzart...@googlemail.com> wrote: > Thanks for your time Mike, Cal, Andre! > I had suspected that general consensus will be don't use admin :) > still I had to ask. When i write down all the features admin has and > features i will need to be created on top of admin somehow, i've > come to the same conclusions. Still it hurts me a lot to be > implementing the same old CRUD over and over again. > Anyhow, thanks for sharing ! > mars > > On 19 Paź, 18:56, Mike Seidle <m...@seidle.net> wrote: > > > > > > > > > On Wednesday, October 19, 2011 02:10:49 PM Andre Terra wrote this and sent > > it > > to To: django-users@googlegroups.com:: > > > > > To be honest, you're probably (not 100% sure) creating *more* work for > > > > yourself trying to make something like this work in django admin, than > > > > just designing something for yourself (YMMV). > > > > I couldn't agree more. Too often I see newcomers learning how to extend > > > the > > > admin, when it would actually be easier to roll out their own views, not > > > to > > > mention how they would be learning how to use the framework rather than a > > > built-in app. > > > It's so easy to think Django-Admin is the answer. Django's admin is a few > > steps up from PHPMyAdmin or some other SQL GUI tool. Uless your use case for > > your user is precicely a create, read, update and delete interface to your > > data as represented by your model definitions, you probably will not have > > the > > moving parts you need to implement what you want... The minute you want > > more/different, is (most of the time) literally less work to just roll your > > own > > view and template which will give you much more control of the user > > experience > > and avoid the inevitable complaints about "why aren't totals at the bottom > > of > > tables? How come we have to used this wonky Year/Month/Date drill down? > > > --- Mike -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
