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

2016-01-31 Thread Shai Berger
Hi Aymeric, Your message seems to be confusing the queryset API with the model-instance API. Details below. On Sunday 31 January 2016 21:24:17 Aymeric Augustin wrote: > > 1) Ignore some fields on updates > > Django already provides three ways to do this: > >

Re: Form field labels change proposal

2016-01-31 Thread Sergei Maertens
I've done the initial work for a patch, assuming a 'hard' change without deprecation path, the branch is here: https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4. Tests should be passing. I've also taken a quick glance at django-admin-tools to check if

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

2016-01-31 Thread Aymeric Augustin
Hello Owais, I had flagged this for review but it didn’t make it to the top of my list until today, sorry. The current approach adds 7 new APIs that only target the use case exposed in the ticket, which I find rather narrow. Some of these APIs (ignore_delegated) only exist to work around the

Re: View permissions to admin

2016-01-31 Thread Petr Dlouhý
Hi Markus, Adam, I looked to Django admin documentation ( https://docs.djangoproject.com/en/1.9/ref/contrib/admin/). I don't see anything discouraging from such usage, but rather I see encouraging for usage as interface for content managers: "One of the most powerful parts of Django is the

Re: View permissions to admin

2016-01-31 Thread Adam Johnson
Hi, At YPlan we've hacked in view permissions to the admin, exactly because of the reasons Markus talked about - it's the front end we've built for employees, done rather than building a proper process-based interface. I think it could just about be done in a third-party package (It might rely

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

2016-01-31 Thread Owais Lone
Tim, I assumed the explanation and discussion on the ticket would be enough. I'll write it up if I find some time next week. Thanks On Saturday, January 23, 2016 at 2:39:45 AM UTC+5:30, Tim Graham wrote: > > It would be helpful if you could sketch out the proposal a bit more -- > maybe write

Re: should manage.py test run system checks?

2016-01-31 Thread Žan Anderle
Same for us. It takes slightly longer because of some custom checks, but it's still under a second. Dne nedelja, 31. januar 2016 10.23.30 UTC+1 je oseba Adam Johnson napisala: > > Y'all know my position (original author). How long are the checks taking > for people? We have a very large project

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

2016-01-31 Thread Adam Johnson
Just to play devil's advocate... you're all worrying about one simple case; there are infinite variants of it with subtle bugs, for example imagine the same situation but with *Value*: Whatever.object.filter(is_active=Value('false')) The ORM can't predict the type of a *Value* call - pretty

Re: Deprecate Cache.has_key()?

2016-01-31 Thread Adam Johnson
Might be problematic for third-party cache backends which implement *has_key* and rely on *__contains__* calling it - don't see how you can show the warning in that case. On Saturday, January 30, 2016 at 12:34:14 PM UTC, Tim Graham wrote: > > Yes, but dict.has_key() is removed in Python 3. If

Re: should manage.py test run system checks?

2016-01-31 Thread Adam Johnson
Y'all know my position (original author). How long are the checks taking for people? We have a very large project with >100 models, ~30 apps, and it still takes less than a second. On Thursday, October 22, 2015 at 12:15:59 PM UTC+1, Žan Anderle wrote: > > Adam: I don't think they should be