Re: Replacing the contrib.sites Site model with a setting?

Could we make the sites portion of Django an interface? In settings you give something like SITES_PROVIDER = 'myapp.sites.MultiTenancySite', and that provider then needs to fulfill a given API. This way we wouldn't need to offer anything complex in-built, but users would be free to do whatever

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

The options for save() API seem to be: 1. refresh_fields=[...] for save() - if set, then issue RETURNING for fields mentioned in the refresh_fields API. 2. expressions: my_model.updated_at = TransactionNow(); my_model.save(), where TransactionNow is flagged to refresh the value from DB post-s

Re: #10686 - inheritance of extra permissions from base class to child class

Thanks for the input, that clears up some details which bring me on agreement for the first suggestion. Op 2 feb. 2016 21:51 schreef "Shai Berger" : > Hi Sergei, > > Two notes: > > 1) For Abstract base classes, Meta is inherited by default[1] which would > make > the permissions inherited by defau

Re: Remove null assingment check for non-nullable fields?

On Wednesday, February 3, 2016 at 1:26:26 AM UTC+2, Tim Graham wrote: > > There's a proposal to remove this behavior: > > > >>> obj.fk = None > ValueError('Cannot assign None: "Obj.fk" does not allow null values.) > I don't see this check as necessary - if you try to save such an object you will

Re: #26165 new Cleanup/optimization wanted to start with a documentation ticket

Thanks. I was going to add the questions at the end of the csrf.txt. Thanks for the help. I have claimed the ticket. I will send a pull request in a day or two. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" g

Admin Improvement - Autocomplete & improved search for FKs

Hello, On one of my projects I'm using django-grappelli to improve the admin

Re: Remove null assingment check for non-nullable fields?

With respect to rationale 2: It makes sense to remove this check as database handle these checks very well. And just like uniqueness checks, it is nice to let database do its work. With respect to rationale 1: Since this behaviour will ask developers to change exception catching from ValueError to

Remove null assingment check for non-nullable fields?

There's a proposal to remove this behavior: >>> obj.fk = None ValueError('Cannot assign None: "Obj.fk" does not allow null values.) (i.e. no more exception if you assign None to a non-nullable foreign key) Rationale presented on the ticket [1]: - Conceptually it is a programmer's respon

Re: #26165 new Cleanup/optimization wanted to start with a documentation ticket

The FAQ is at: https://github.com/django/django/tree/master/docs/faq Depending on how much content there is, it might make more sense to add the questions on the CSRF reference page instead: https://github.com/django/django/blob/master/docs/ref/csrf.txt Please read the contributing documentation

#26165 new Cleanup/optimization Wanted to start with a documentation ticket

Hi, I wanted to start with a documentation ticket. https://code.djangoproject.com/ticket/26165 I have read through the thread and have made some questions and answers. How should I proceed? Should I claim the ticket ? Where can I start writing? Tha

#26165 new Cleanup/optimization wanted to start with a documentation ticket

I wanted to start with a documentation ticket while I get myself acquainted with the code base. I have seen the thread referenced and I can make relevant questions and answers from it . These questions and answers will go to the FAQ page regarding why Django's CSRF protection isn't vulernable.

Re: #10686 - inheritance of extra permissions from base class to child class

Hi Sergei, Two notes: 1) For Abstract base classes, Meta is inherited by default[1] which would make the permissions inherited by default. For multi-table inheritance, this is not the case[2]. 2) The second option as you presented it, where AssignedTask.Meta's permissions are added to its par

Re: remove support for unsalted password hashers?

> For testing, Django provides force_login(). This method skips password hashing > and logs a user in for a test. For tests that want a logged in user and do not > care about how the password was verified, this seems like a good choice. > Assuming this was used throughout, would this be sufficien

Re: remove support for unsalted password hashers?

> For testing, Django provides force_login(). This method skips password hashing > and logs a user in for a test. For tests that want a logged in user and do not > care about how the password was verified, this seems like a good choice. > Assuming this was used throughout, would this be sufficien

Re: remove support for unsalted password hashers?

> On Feb 2, 2016, at 1:52 PM, Tim Graham wrote: > > Just to be clear, my proposal here is only about removing > UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted versions > of these hashers remain. It seems silly to remove the unsalted options and leave the salted options

Re: remove support for unsalted password hashers?

Just to be clear, my proposal here is only about removing UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted versions of these hashers remain. I don't think the unsalted versions have any speed advantages as far as testing goes compared to the salted versions? Django's test se

Re: remove support for unsalted password hashers?

On Tue, Feb 2, 2016 at 10:35 AM, charettes wrote: >> That hasher, being the fastest non-plaintext hasher around, is quite >> useful >> when running tests: it allows login checks to be performed much faster. > > This argument came up a couple of time in the past and from what I remember > the Djang

Re: remove support for unsalted password hashers?

> That hasher, being the fastest non-plaintext hasher around, is quite useful > when running tests: it allows login checks to be performed much faster. This argument came up a couple of time in the past and from what I remember the Django test suite itself spends a significant amount of time has

Re: remove support for unsalted password hashers?

Hi Tim, I would suggest removing those hashers from the default list, but keeping at least the django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around. That hasher, being the fastest non-plaintext hasher around, is quite useful when running tests: it allows login checks to be performed muc

Re: [admin] submit_row template tag reusability issue

The patch is 5 years old and doesn't apply cleanly, so it needs improvement in that sense but that shouldn't be difficult. The main blocker to getting it merged looks like "Needs tests." On Tuesday, February 2, 2016 at 10:58:40 AM UTC-5, Federico Capoano wrote: > > Hi Tim, > > thank you for lett

remove support for unsalted password hashers?

Django 0.90 stored passwords as unsalted MD5. Django 0.91 added support for salted SHA1 with automatic upgrade of passwords [0]. In Django 1.4, the new password hashing machinery was added and some users complained that they couldn't upgrade because the password format from Django 0.90 was no l

Re: [admin] submit_row template tag reusability issue

Hi Tim, thank you for letting me know of the open ticket. The "patch needs improvement" flag is set to "no". Is that correct or not? Federico On Mon, Feb 1, 2016 at 1:18 PM Tim Graham wrote: > Here is an accepted ticket: https://code.djangoproject.com/ticket/13875 > > Feel free to update and/o

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

thank you all for your feedback. I think it would be good to reference from the individual page to the matching comparison grid (if one exists). It tells newcomers: Professionals do re-use, they don't re-invent. For example the python docs sometimes have a box called "See also" which contains l

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

My main concern is that it might appear that Django officially endorses the website, and that it might not be clear to developers that Django isn't directly involved with all those third party packages - which could be potentially harmful. I'm also think that if you start linking to a grid for

#10686 - inheritance of extra permissions from base class to child class

Hi all, I was browsing tickets and stumbled upon https://code.djangoproject.com/ticket/10686, which was accepted except for lack of documentation. The patch in the mentioned ticket makes it so that a Model class that's used as base class with extra permissions: class BaseTask(models.Model):

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

Ok, got that sorted now. How about the fix, is it reasonable? Den tisdag 2 februari 2016 kl. 11:51:19 UTC+1 skrev is_null: > > Just click "Details" and then "Console output". You'll find this: > > + flake8 > ./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid > syntax >

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

Just click "Details" and then "Console output". You'll find this: + flake8 ./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid syntax ERROR: /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py Imports are incorrectly sorted. --- /home/jenkins/workspace/isort

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

Thanks for the feedback! I have updated the PR, can someone have a look at it again? I noticed that there where failing checks (flake8, isort) but it does not say why that it, do I need to fix something? Cheers Tore Lundqvist Den fredag 29 januari 2016 kl. 15:20:11 UTC+1 skrev Tore Lundqvist:

Re: Query on BooleanField with values other than True and False, bug or intentional?

I don't think enforcing it would be pythonic. Once upon a time, Python lacked True and False, all you had were truthy and falsey and maybe per-project/team constants: http://python-history.blogspot.no/2013/11/story-of-none-true-false.html I remember the arguments when bool() was added. Those aga