Re: Redirect loop detection in test client is incorrect

Hi Scott, On Sunday 07 February 2016 04:34:59 Luke Scott wrote: > Not sure if this is where I should comment on this issue but I just > upgraded to Django 1.8 and am encountering this error: > > RedirectCycleError: Redirect loop detected. > > > I have a view that looks for a certain conditi

Re: Redirect loop detection in test client is incorrect

Not sure if this is where I should comment on this issue but I just upgraded to Django 1.8 and am encountering this error: RedirectCycleError: Redirect loop detected. I have a view that looks for a certain condition. If that condition is not met then I redirect to a second view. That secon

Re: #25897 - managers defined on non-abstract base classes inherited by child classes

Thank you for the suggestion. Pull request is adjusted to give deprecation warning instead of raising AttributeError. Yes, to silence the warning manager need to be be added to any subclass explicitly. It is explained in documentation

Fellow Report - February 6, 2016

Triaged --- https://code.djangoproject.com/ticket/26162 - Data loss when ManyToManyField refers to the wrong table (accepted) https://code.djangoproject.com/ticket/26168 - BooleanField is forced to be blank=True (accepted) https://code.djangoproject.com/ticket/26171 - ForeignKey with d

Re: default values on database level

Hi all, I've a working PR that implements this but in a much inferior way https://github.com/django/django/pull/5904 I'm very interested in this and would love to contribute. Has anyone started work on this? If not, I'd like to pick it up. -- Owais On Tuesday, August 4, 2015 at 12:05:33 AM UTC

Re: [Review Request] Added support for database delegated fields (like AutoField)

Shai and Ayeric, thank you so much for the feedback. The PR did indeed snowball into a much bigger one that I had initially planned. I agree with all points except, > - controlling this behavior in the query rather than in the field definition — this avoids the awkward “ignore what the field sa

Re: remove support for unsalted password hashers?

I kept meaning to weigh in on this... but all my points have been made. It sounds like the middle ground is to: 1) remove them from the default list 2) keep them in the codebase 3) make them noisy (raise warnings) 4) provide docs/tools on how to upgrade Then we get "secure by default" (1), as w

Re: remove support for unsalted password hashers?

Yes, that would be good from the “security by default” standpoint. This would also allow us to trim the full list of hashers which is repeated several times in the docs. -- Aymeric. > On 6 févr. 2016, at 00:03, Tim Graham wrote: > > I would guess most users aren't customizing the default lis