#27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

I'm not a fan of adding more complexity, for a couple reasons: 1) you have the ['*'] option for local / office development 2) you can just add a record to /etc/hosts to point to the server and then use a name like e.g., local-office - just update the record to point to whatever IP you're using

#27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

Hi The other day I raise a ticket to do with ALLOWED_HOSTS and it was suggested that I post on this group before creating a patch The ticket is https://code.djangoproject.com/ticket/27485 The problem Now that Django 1.10.3 forces ALLOWED_HOSTS on with debug I have a problem. The problem is

Re: Feature idea

Sending a link to set a password isn't much better. Perhaps a way to force a password change on login would be better, which has more use elsewhere, such as being able to periodically force password changes On 16 Nov 2016 8:13 p.m., "Aymeric Augustin" < aymeric.augus...@polytechnique.org> wrote:

Re: Feature idea

Hello, I wouldn’t dismiss the idea so quickly. Adding staff users from your company is a fairly common use case. Currently you have to email them a password and ask them to change it. This doesn’t set a good example. The better solution is SSO with the corporate directory (often

Re: Feature idea

I don't think this registration model is common on most websites. On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da Silva wrote: > > Hello everyone, > > I have this simple idea that I think django could benefit from, which > would be the option to create a user by an

Feature idea

Hello everyone, I have this simple idea that I think django could benefit from, which would be the option to create a user by an invitation from the django admin page. So the person who is creating a new user doesn't have to type a password neither a username for this new user. He would only fill

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

> On 16 Nov 2016, at 16:35, Mark Young wrote: > > Once I know the preferred fix, I'll work on the patch. Unfortunately the hard part is to figure out what the preferred fix is :-/ It's likely to be a trivial one liner. Tests may be a bit more involved. > One thing I still

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

Re fixing transaction.rollback: What would be the preferred way to fix this? I haven't personally tested it (a coworker has and reports that it doesn't work), but BaseDatabaseWrapper.set_rollback requires that in_atomic_block be True when set_rollback is called, which is not the case in this

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

Hello Mark, Indeed this is the bug described in https://code.djangoproject.com/ticket/26340 . It hasn’t been fixed yet because things become complicated with savepoints and because it isn’t obvious that it cannot introduce data corruption bugs.

DatabaseWrapper.needs_rollback and transaction.rollback()

After a validationError occurs, why is the transaction considered dirty, blocking all db reads/writes? In this example: https://bitbucket.org/marky1991/django-test/raw/59c9ff89e4b12b4a831c36171139cb022735201b/test1.py , I don't really expect a TransactionManagementError at all, as the failure

Re: Template-based widget rendering

I took a stab at backwards-compatibility with respect to allowing the admin to work without adding 'django.forms' to INSTALLED_APPS. It seems to work for at least the simple TEMPLATES = 'BACKEND': 'django.template.backends.django.DjangoTemplates', ...} case, although I'm not proud of the code

django.core.file.storage.FileSystemStorage strange behavior

Hello everyone! I'm using django 1.9.10. (It is the same on 1.10.x) After two day tracking an obscure bug I found it in the behavior of FileSystemStorage.exists. I was using django compressor and it store compressed files in the django CACHE folder with a random name. It seems that the first