Re: Making Django more PaaS-friendly

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: Usage of DjangoRuntimeWarning

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

Re: NumericListfilter or similar

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: One Click Django Installer

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: IntegrityError when cascading delete, and there post_delete that creates a new object.

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

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

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

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

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

Re: Making Django more PaaS-friendly

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

Re: Decoupling Permission-Check from Calling the View

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

Decoupling Permission-Check from Calling the View

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.