Let's talk with a concrete (real but simplified) example. There's a database of documents. Some documents are publicly available, whereas some are available only to logged-on users.
The "document list" view shows all documents if you're logged-on, and a subset if not. The "document detail" view will return 404 if the document is private and you're not logged on. The "document download" view will do the same. Edge case: Besides documents, the database also contains projects. The "project detail" view displays among other things this note: "25 reports are available for this project". The "project detail" view definitely has very little to do with the "document detail" view and it is a different view, and the programmer forgets to include the mix-in. The number displayed may be wrong (this is relatively harmless but it illustrates the problem). By implementing what I proposed, I solve this problem once and for all, regardless what functionality will be developed in the future and whether the programmer who develops that functionality is trying to cure a broken heart with hard work after a sleepless night of heavy drinking. I'm playing the devil's advocate here. Many people seem to dislike my proposal, and I'm trying to understand why. Antonis Christofides http://djangodeployment.com On 2017-03-11 16:08, Melvyn Sopacua wrote: > > On Thursday 09 March 2017 14:36:55 Antonis Christofides wrote: > > > > > Exactly, "if you remember to write a test". Unit tests can help, but > > > when you do the same kind of permissions checking 10 times in 10 > > > different places of the app, it's really hard to know that you failed > > > to check edge case XYZ. > > > > This sounds more and more like you haven't got a good inheritance chain for > your CBV's. > > Take a look at Django Guardian: it has a different method for fetching objects > a user has access to. If you inject that in a class that overrides > SingleObjectMixin.get_object() and it's counterpart > MultipleObjectMixin.get_queryset(), you can setup an inheritance chain that > does all the work for you. > > But without some code examples for those edge cases and their view > inheritance, it's hard to predict and it may be comfy to have a 2nd line of > defence at the manager level. > > > > -- > > Melvyn Sopacua > > -- > 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 > <mailto:django-users+unsubscr...@googlegroups.com>. > To post to this group, send email to django-users@googlegroups.com > <mailto:django-users@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/2599535.PjUGXTrGZr%40devstation > <https://groups.google.com/d/msgid/django-users/2599535.PjUGXTrGZr%40devstation?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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 https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/90483c9f-1e7b-6772-b151-cfefb35ca37a%40djangodeployment.com. For more options, visit https://groups.google.com/d/optout.
