Decoupling Permission-Check from Calling the View

2016-04-26 Thread guettli
I would like to decouple the permission checking in django. Current draw-back: If you use decorators like [login_required][1], then you can't know in advance whether a user has the permission to do so or not. I would like to split this into two steps: 1. check permissions 1. call the view.

Re: Decoupling Permission-Check from Calling the View

2016-04-26 Thread Alasdair Nicol
I haven't needed to explain why permission has been granted, but I have had admins asking me why a user is getting permission denied for a particular view. To answer that, you would 1. Get the url 2. Resolve that to a view 3. Look up the view in the correct views.py, and check which permissions

IntegrityError when cascading delete, and there post_delete that creates a new object.

2016-04-26 Thread Paulo Maciel
Hi, I have a problem that already published in Django users, but did not find the solution to this. When deleted in cascade and a relationship has a post_delete that creates an entry to a deleted object, an error occurs and the exception does not work. Please look at this https://groups.googl

Re: Making Django more PaaS-friendly

2016-04-26 Thread Hanne Moa
On 12 April 2016 at 05:35, Martin Owens wrote: > There is a difference between settings intended by developers to be used by > other developers /../ And settings used by systems administrators to define > the environment they are deployed to as well as any deployment specific > controls. > > Djang

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

2016-04-26 Thread Tim Graham
It seems there was request.body checking in previous iterations of the PR but it was dropped for reasons that aren't entirely clear to me: https://github.com/django/django/pull/3852#discussion_r35350372 On Wednesday, April 20, 2016 at 9:30:48 PM UTC-4, Cristiano Coelho wrote: > > Hi, > > In parti

Re: #26481 - Add a "strict mode" for defer()/only()

2016-04-26 Thread Tim Graham
I guess there's some question about whether or not we need to make changes in Django given Anssi's comment, "Overriding Model.refresh_from_db() allows raising failure when deferred field is accessed - is this enough for you use case?" On Friday, April 22, 2016 at 7:07:07 AM UTC-4, Fabien SCHWOB

Re: IntegrityError when cascading delete, and there post_delete that creates a new object.

2016-04-26 Thread Tim Graham
Hi, sorry but this mailing list isn't a second level support channel if you don't get a question answered on django-users. On Tuesday, April 26, 2016 at 1:14:30 PM UTC-4, Paulo Maciel wrote: > > Hi, I have a problem that already published in Django users, but did not > find the solution to this.

Re: One Click Django Installer

2016-04-26 Thread Tim Graham
This mailing list is about the development of Django itself. The django-users mailing list would be more appropriate for a message like this. On Sunday, April 24, 2016 at 11:53:19 AM UTC-4, Ankit Kumar wrote: > > Check this video : > > > https://www.youtube.com/watch?v=85P3Qn9Sccs >

Re: NumericListfilter or similar

2016-04-26 Thread Tim Graham
Does it need to be in Django itself? I'd think probably not, at least to start, but if there's something prohibiting that, then let us know. On Tuesday, April 19, 2016 at 1:19:02 PM UTC-4, John Griebel wrote: > > I agree that we need a replacement; the current behaviour isn't all that > useful,

Re: Usage of DjangoRuntimeWarning

2016-04-26 Thread Tim Graham
I think warnings.filterwarnings(RuntimeWarning, module="django..") might allow filtering without a subclass? According to the ticket, Carl offered the version of the patch with DjangoRuntimeWarning "following design discussion with Russell K-M, Malcolm T, Jannis L, and Jeremy Dunck." (in case a

Re: Making Django more PaaS-friendly

2016-04-26 Thread Marcin Nowak
Hi all, On Wednesday, April 13, 2016 at 9:58:18 PM UTC+2, Carl Meyer wrote: > > Hi James et al, > > In general, I like the idea of adding a helper to Django to read > settings from the environment. I think this helper should be kept as > simple and non-magical as is reasonable. Thus: > > This

Re: Making Django more PaaS-friendly

2016-04-26 Thread Aymeric Augustin
Hello, If anything, this discussion shows that people have come up with a wide variety of customized solutions to meet their use cases. That supports Django’s historical decision not to be too prescriptive in this area. I still think James’ proposal is valuable because it will nudge developers to