date:20150414

Re: [Django] #24424: Removing a model's last field results in SQL syntax error on SQLite

2015-04-14 Thread Django

#24424: Removing a model's last field results in SQL syntax error on SQLite
+
 Reporter:  adnam   |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by jwineinger):

 The case below is nearly exactly the same one I ran into.

 {{{#!python
 # models.py
 from django.db import models

 class Thing(models.Model):
 pass

 class Blob(Thing):
 pass


 # 0001_initial.py
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import migrations, models


 class Migration(migrations.Migration):

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='Thing',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ],
 ),
 migrations.CreateModel(
 name='Blob',
 fields=[
 ('thing_ptr', models.OneToOneField(auto_created=True,
 parent_link=True, primary_key=True, serialize=False, to='app_a.Thing')),
 ],
 bases=('app_a.thing',),
 ),
 ]
 }}}

 Making `Thing` inherit a new model `Bar`:

 {{{#!python
 # models.py
 from django.db import models

 class Bar(models.Model):
 pass


 # 0002_auto.py
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import models, migrations


 class Migration(migrations.Migration):

 dependencies = [
 ('thing', '0001_initial'),
 ]

 operations = [
 migrations.RemoveField(
 model_name='blob',
 name='thing_ptr',
 ),
 migrations.DeleteModel(
 name='Blob',
 ),
 ]
 }}}

 {{{
 ./manage.py migrate
 Operations to perform:
   Synchronize unmigrated apps: staticfiles, messages
   Apply all migrations: auth, admin, thing, sessions, contenttypes
 Synchronizing apps without migrations:
   Creating tables...
 Running deferred SQL...
   Installing custom SQL...
 Running migrations:
   Rendering model states... DONE
   Applying contenttypes.0001_initial... OK
   Applying auth.0001_initial... OK
   Applying admin.0001_initial... OK
   Applying contenttypes.0002_remove_content_type_name... OK
   Applying auth.0002_alter_permission_name_max_length... OK
   Applying auth.0003_alter_user_email_max_length... OK
   Applying auth.0004_alter_user_username_opts... OK
   Applying auth.0005_alter_user_last_login_null... OK
   Applying auth.0006_require_contenttypes_0002... OK
   Applying sessions.0001_initial... OK
   Applying thing.0001_initial... OK
   Applying thing.0002_auto_20150415_0113...Traceback (most recent call
 last):
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/db/backends/sqlite3/base.py", line 318, in execute
 return Database.Cursor.execute(self, query, params)
 sqlite3.OperationalError: near ")": syntax error

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 338, in
 execute_from_command_line
 utility.execute()
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 330, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/core/management/base.py", line 390, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/core/management/base.py", line 441, in execute
 output = self.handle(*args, **options)
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/core/management/commands/migrate.py", line 221, in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-
 packages/django/db/migrations/executor.py", line 110, in migrate
 self.apply_migration(states[migration], migration, fake=fake,
 fake_initial=fake_initial)
   File "/Users/jawineinger/venvs/test/lib/python3.4/site-

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-04-14 Thread Django

#24622: Response "context" and "templates" not available in the Test Client when
using Jinja2 - Django 1.8
-+
 Reporter:  rivantis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  jinja2, test client  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by carljm):

 Oh yes, Armin did mention that he intentionally doesn't provide any hooks
 into anything context-related after the initial render, so it seems that's
 not likely to change. A couple approaches he mentioned that we could look
 into:

 ```
 22:11 < mitsuhiko> if you want to intercept the context somehow, you could
 do things
 22:11 < mitsuhiko> but it's pretty ugly
 22:11 < mitsuhiko> you can set a custom template_class on the environment
 22:11 < mitsuhiko> and then in that template class you patch
 root_render_func and all funcs in blocks
 22:11 < mitsuhiko> as they are passed the context
 22:12 < mitsuhiko> maybe you also get away with overriding new_context
 ```

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1e805f5824052b9c01378b4c1fdf7641%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-04-14 Thread Django

#24622: Response "context" and "templates" not available in the Test Client when
using Jinja2 - Django 1.8
-+
Reporter: rivantis |Owner: nobody
Type: Bug | Status: new
Component: Testing framework| Version: 1.8
Severity: Normal | Resolution:
Keywords: jinja2, test client | Triage Stage: Accepted
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+

Comment (by prestontimmons):

Thanks for looking into that, Carl.

First, I agree that it would be nice to remove the DTL monkeypatch. We
might be able to do this by adding an `enable_signals` option to the
Django backend. This way signals could be enabled or disabled via the
`TEMPLATES` setting. I'll look into this further to see if I'm missing
anything here. (#14365)

Second, while an `Environment` subclass for Jinja2 is definitely cleaner,
it may be insufficient for the bigger use cases outside this ticket. From
what I can tell, `Environment._load_template` doesn't have access to
context variables. Django uses the same signal to populate
`response.context` and `response.templates`. Context variables are also
used in the Django debug toolbar template panel. I guess we could patch in
the instrumentation at the instance level, here, though. That's not great
but it's an improvement over changing Jinja2 internally.

Also, I suppose any signal here should send an instance of the backend
template class rather than the internal template class. For
`assertTemplateUsed` to work, we need to ensure the signalled template
objects have a `name` attribute.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.495d58751acfd49b34c5ad63f0ede106%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24643: views.generic.edit.FormMixin should have a get_context_data() method

2015-04-14 Thread Django

#24643: views.generic.edit.FormMixin should have a get_context_data() method
--+
 Reporter:  akulakov  |Owner:  akulakov
 Type:  Cleanup/optimization  |   Status:  new
Component:  Generic views |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_docs:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 It seems some documentation about backwards compatibility and updates to
 the methods in the class-based views reference documentation are required.
 Also, it might be nice to have a test to demonstrate the usefulness of the
 change.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.91a3cf08310a92bd960b810feb20295c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24644: Added HTTP_ACCEPT in the documentation

2015-04-14 Thread Django

#24644: Added HTTP_ACCEPT in the documentation
--+
 Reporter:  adminq80  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.18a337c9ddc08f49298fb9e8efb416ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24644: Added HTTP_ACCEPT in the documentation

2015-04-14 Thread Django

#24644: Added HTTP_ACCEPT in the documentation
-+-
 Reporter:  adminq80 |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by adminq80):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> Hello guys, I added HTTP_ACCEPT to the HttpRequest.META example list in
> docs/ref/request-response.txt.
>
> Thanks,
> Abdulrahman Alotaibi

New description:

 Hello guys, I added HTTP_ACCEPT to the HttpRequest.META example list in
 docs/ref/request-response.txt. I added a github pull request that does
 that https://github.com/django/django/pull/4515

 Thanks,
 Abdulrahman Alotaibi

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.918f1b9194e3a33261565bca47d22ea3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24644: Added HTTP_ACCEPT in the documentation

2015-04-14 Thread Django

#24644: Added HTTP_ACCEPT in the documentation
--+
 Reporter:  adminq80  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Hello guys, I added HTTP_ACCEPT to the HttpRequest.META example list in
 docs/ref/request-response.txt.

 Thanks,
 Abdulrahman Alotaibi

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.a01be134f325b5e902ad7cafe9f8a81e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24385: Sum() doesn't seem to respect .distinct() in the queryset filter before .aggregate() when filtering by m2m.

2015-04-14 Thread Django

#24385: Sum() doesn't seem to respect .distinct() in the queryset filter before
.aggregate() when filtering by m2m.
-+-
 Reporter:  mcagl|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => fixed


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.3834619c75e7ee4a47ecc042b54b3427%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24385: Sum() doesn't seem to respect .distinct() in the queryset filter before .aggregate() when filtering by m2m.

2015-04-14 Thread Django

#24385: Sum() doesn't seem to respect .distinct() in the queryset filter before
.aggregate() when filtering by m2m.
-+-
 Reporter:  mcagl|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"910638fc4e4f83bda31dd91db5017acb06dfc8d2" 910638f]:
 {{{
 #!CommitTicketReference repository=""
 revision="910638fc4e4f83bda31dd91db5017acb06dfc8d2"
 Refs #24385 -- Added tests for distinct sum issue fixed in
 c7fd9b242d2d63406f1de6cc3204e35aaa025233
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.e5d0be678d0e34924823baa135a8c14d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24640: Add AbstractUser.get_display_name()

2015-04-14 Thread Django

#24640: Add AbstractUser.get_display_name()
--+--
 Reporter:  atmb4u|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by MarkusH):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 I agree with Tim. In all projects I run, the requirements differ on what
 the "display name" should be. Some projects even have an explicit "display
 name" attribute for the user to fill.

 Feel free to bring this topic up on the
 [https://groups.google.com/forum/#!forum/django-developers django-
 developers mailing list], but for now I'm closing this issue as wontfix.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.be43eab4c908106f8f07634fd714481f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24622: Response "context" and "templates" not available in the Test Client when using Jinja2 - Django 1.8

2015-04-14 Thread Django

Comment (by carljm):

I talked to Armin in IRC today and I think there might be a variant of
option (3) that wouldn't be too bad. Armin says that
`Environment._load_template`, while marked as private API, is stable
enough to safely override, and all template renders (not just top-level)
go through it. (Disclaimer: I haven't looked at code in detail, just
relaying here). So instead of monkeypatching Jinja2, we could maybe
provide our own subclass of `Environment` that people can use if they want
this feature. The main detail to work out would be whether this
`Environment` subclass always fires signals or only does it during test;
even if we enabled it via monkeypatch like we do for DTL, we could at
least be monkeypatching our own code in the subclass rather than Jinja2
directly.

(Personally I think we should rework the DTL system to not rely on
monkeypatching either, but this requires some design decisions. It may be
that the signals framework is fast enough in the no-listeners case now
that we can safely just always send these signals, instead of monkey-
patching them in for testing only.)

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.3bdbe23fcfa07ace8d00180e4b9a6799%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21652: Make ``loaddata`` notify about how many objects from fixture got processed

2015-04-14 Thread Django

#21652: Make ``loaddata`` notify about how many objects from fixture got 
processed
-+-
 Reporter:  while0pass   |Owner:  yitzc
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 I think using `\r` would make more sense here.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.4960a48f0bad420492ce08d38a410df0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24636: InvalidOperation saving decimal.Decimal

2015-04-14 Thread Django

#24636: InvalidOperation saving decimal.Decimal
-+-
 Reporter:  glic3rinu|Owner:
 |  iuliachiriac
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  InvalidOperation | Triage Stage:  Accepted
  decimal Decimal|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by iuliachiriac):

 I have added a validator to check that the input is less than `10 **
 (max_digits - decimal_places)`

 Here is the pull request: https://github.com/django/django/pull/4514

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c38eb7d4174900e14e8d3ecd5384d63d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24605: Database identifiers are not properly escaped in some queries

2015-04-14 Thread Django

#24605: Database identifiers are not properly escaped in some queries
-+-
 Reporter:  kurevin  |Owner:
 |  priidukull
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression,  | Triage Stage:  Accepted
  database   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Your testcase probably sporadically fails and pass because of dict
 ordering.

 I guess the following would always trigger a failure:

 {{{#!python
 Amodel.objects.exclude(Q(bmodel__id=False), Q(cmodel__isnull=True))
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.72be0fd195fa322869f79328f8e9d064%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

2015-04-14 Thread Django

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sqlite | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by charettes):

 From what I learned from the sprint it looks like homebrew builds Python
 with the currently installed version of SQLite hence the failures on
 different versions here.

 What should be really useful to isolate the bug would be to try rebuilding
 Python with different versions of SQLite, create a virtualenv with this
 newly installed python interpreter and run something along those lines:

 {{{
 /path/to/intepreter/python -c"
 import sqlite3
 connection = sqlite3.connect(':memory:')
 cursor = connection.cursor()
 cursor.execute('SELECT sqlite_version()')
 print(cursor.fetchone())
 "
 }}}

 To try to figure out which version of SQLite provided by Homebrew we
 should advise not to build Python with.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.813797191a40ecfd6ee576507a84a11b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24593: Thousand separator not showing in ModelAdmin.readonly_fields

2015-04-14 Thread Django

#24593: Thousand separator not showing in ModelAdmin.readonly_fields
-+-
 Reporter:  liwee|Owner:  xblitz
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Thousand separator   | Triage Stage:  Accepted
  readonly   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"d72e0178e9930c9967c6fe6cd8c94b3413a240f9" d72e017]:
 {{{
 #!CommitTicketReference repository=""
 revision="d72e0178e9930c9967c6fe6cd8c94b3413a240f9"
 Fixed #24593 -- Fixed number formatting of readonly IntegerFields in the
 admin.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.118fd649df7d4cd63f7e74612faf82d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #8122: Better way of testing for cookies

2015-04-14 Thread Django

#8122: Better way of testing for cookies
--+
 Reporter:  jcassee   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by kutenai):

 * Attachment "8122-rmaster.diff" added.

 Updated the diff to the latest master

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b4094382c07c24a568b9a137fa436bd2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-14 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+-
 Reporter:  simonpercivall   |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.da6aaba5050e86491f5cd230d7cf6ffc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24643: views.generic.edit.FormMixin should have a get_context_data() method

2015-04-14 Thread Django

#24643: views.generic.edit.FormMixin should have a get_context_data() method
-+-
 Reporter:  akulakov |Owner:  akulakov
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akulakov):

 * has_patch:  0 => 1


Old description:

> Currently SingleObjectMixin and MultipleObjectMixin have get_context_data
> but FormMixin does not, instead form is added to context via an argument
> in get() method.
>
> The reason for this is probably because it's just one line of code and it
> did not seem to warrant a method.
>
> However, it would be really nice to have this method for a few reasons:
>
> 1. consistency: FormView, UpdateView, CreateView context gets populated
> in the same way as in DetailView and ListView. When GCBVs are customized,
> users will know that context is populated in the same place for all
> views.
>
> 2. From the point of view of documentation, it's also easier because you
> can tell users where context is created for all views rather than
> specifying two different places, especially because you have to explain
> that argument to get_context_data gets added to context.
>
> 3. Logically, it seems like it should belong to get_context_data(). A
> user who is not closely familiar with GCBVs may be confused as to where
> context comes from in Form Views. get_context_data() is an unambiguous
> location for this logic as indicated by the name.
>
> 4. It makes it easier to combine different GCBVs. In case of FormView and
> CreateView, you don't need to do anything in get() method (in CreateView
> you may simply init self.object=None at class level), therefore when
> combining these views with others, you can simply use get() methods from
> the other View and let get_context_data() handle contexts of all
> inherited views.
>
> There are two alternatives: form initialization may be removed from get()
> and post() methods OR it may be left there along with duplicate logic in
> get_context_data(). In the former case it may be a backwards-incompatible
> change - although get_context_data() is supposed to include a super()
> call to parent get_context_data() methods, users may have it without the
> super() call -- thus form will disappear from context.
>
> If form init is left in get()/post(), it's probably an acceptable
> performance cost. Perhaps it can be left in but deprecated.

New description:

 Currently SingleObjectMixin and MultipleObjectMixin have get_context_data
 but FormMixin does not, instead form is added to context via an argument
 in get() method.

 The reason for this is probably because it's just one line of code and it
 did not seem to warrant a method.

 However, it would be really nice to have this method for a few reasons:

 1. consistency: FormView, UpdateView, CreateView context gets populated in
 the same way as in DetailView and ListView. When GCBVs are customized,
 users will know that context is populated in the same place for all views.

 2. From the point of view of documentation, it's also easier because you
 can tell users where context is created for all views rather than
 specifying two different places, especially because you have to explain
 that argument to get_context_data gets added to context.

 3. Logically, it seems like it should belong to get_context_data(). A user
 who is not closely familiar with GCBVs may be confused as to where context
 comes from in Form Views. get_context_data() is an unambiguous location
 for this logic as indicated by the name.

 4. It makes it easier to combine different GCBVs. In case of FormView and
 CreateView, you don't need to do anything in get() method (in CreateView
 you may simply init self.object=None at class level), therefore when
 combining these views with others, you can simply use get() methods from
 the other View and let get_context_data() handle contexts of all inherited
 views.

 There are two alternatives: form initialization may be removed from get()
 and post() methods OR it may be left there along with duplicate logic in
 get_context_data(). In the former case it may be a backwards-incompatible
 change - although get_context_data() is supposed to include a super() call
 to parent get_context_data() methods, users may have it without the
 super() call -- thus form will disappear from context.

 If form init is left in

Re: [Django] #14671: Allow overriding of ModelChoiceField.choices

2015-04-14 Thread Django

* status: assigned => closed
* resolution: => wontfix

Comment:

I can't think of a use case where it makes sense to add abitrary choices
to the ones available for a ModelChoiceField via its queryset. See
http://stackoverflow.com/questions/5281195/forms-modelchoicefield-
queryset-extra-choice-fields-django-forms for a way to use a normal
ChoiceField to accomplish this.

If the desire is to change the appearance of the choices when they are
rendered, there is the `ModelChoiceField.label_from_instance` method that
can be overridden.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.518a030db36c424d7eec3af9f7037eba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20516: Allow use of prepared statements

2015-04-14 Thread Django

#20516: Allow use of prepared statements
-+-
 Reporter:  est  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db, prepared | Triage Stage:  Accepted
  statement  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shaib):

 On Oracle, the concept of prepared statements is linked to a connection-
 level statement cache. Prepared statements are not handled with different
 SQL, but with different API calls -- specifically, cx_Oracle provides a
 [http://cx-oracle.readthedocs.org/en/latest/cursor.html#Cursor.prepare
 prepare] method on its cursors. This method is not currently used by
 Django's Oracle backend.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.4ccd01df69f3d931115d62326c8346bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24643: views.generic.edit.FormMixin should have a get_context_data() method

2015-04-14 Thread Django

#24643: views.generic.edit.FormMixin should have a get_context_data() method
-+-
 Reporter:  akulakov |Owner:  akulakov
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akulakov):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> Currently SingleObjectMixin and MultipleObjectMixin have get_context_data
> but FormMixin does not, instead form is added to context via an argument
> in get() method.
>
> The reason for this is probably because it's just one line of code and it
> did not seem to warrant a method.
>
> However, it would be really nice to have this method for a few reasons:
>
> 1. consistency: FormView, UpdateView, CreateView context gets populated
> in the same way as in DetailView and ListView. When GCBVs are customized,
> users will know that context is populated in the same place for all
> views.
>
> 2. From the point of view of documentation, it's also easier because you
> can tell users where context is created for all views rather than
> specifying two different places, especially because you have to explain
> that argument to get_context_data gets added to context.
>
> 3. Logically, it seems like it should belong to get_context_data(). A
> user who is not closely familiar with GCBVs may be confused as to where
> context comes from in Form Views. get_context_data() is an unambiguous
> location for this logic as indicated by the name.
>
> 4. It makes it easier to combine different GCBVs. In case of FormView and
> CreateView, you don't need to do anything in get() method (in CreateView
> you may simply init self.object=None at class level), therefore when
> combining these views with others, you can simply use get() methods from
> the other View and let get_context_data() handle contexts of all
> inherited views.
>
> There are two alternatives: form initialization may be removed from get()
> and post() methods OR it may be left there. In former case it may be a
> backwards-incompatible change - although get_context_data() is supposed
> to include a super() call to parent get_context_data() methods, users may
> have it without the super() call, then form will disappear from context.
>
> If form init is left in get()/post(), it's probably an acceptable
> performance cost. Perhaps it can be left in but deprecated.

New description:

 Currently SingleObjectMixin and MultipleObjectMixin have get_context_data
 but FormMixin does not, instead form is added to context via an argument
 in get() method.

 The reason for this is probably because it's just one line of code and it
 did not seem to warrant a method.

 However, it would be really nice to have this method for a few reasons:

 1. consistency: FormView, UpdateView, CreateView context gets populated in
 the same way as in DetailView and ListView. When GCBVs are customized,
 users will know that context is populated in the same place for all views.

 2. From the point of view of documentation, it's also easier because you
 can tell users where context is created for all views rather than
 specifying two different places, especially because you have to explain
 that argument to get_context_data gets added to context.

 3. Logically, it seems like it should belong to get_context_data(). A user
 who is not closely familiar with GCBVs may be confused as to where context
 comes from in Form Views. get_context_data() is an unambiguous location
 for this logic as indicated by the name.

 4. It makes it easier to combine different GCBVs. In case of FormView and
 CreateView, you don't need to do anything in get() method (in CreateView
 you may simply init self.object=None at class level), therefore when
 combining these views with others, you can simply use get() methods from
 the other View and let get_context_data() handle contexts of all inherited
 views.

 There are two alternatives: form initialization may be removed from get()
 and post() methods OR it may be left there along with duplicate logic in
 get_context_data(). In the former case it may be a backwards-incompatible
 change - although get_context_data() is supposed to include a super() call
 to parent get_context_data() methods, users may have it without the
 super() call -- thus form will disappear from context.

 If form init is left in

[Django] #24643: views.generic.edit.FormMixin should have a get_context_data() method

2015-04-14 Thread Django

#24643: views.generic.edit.FormMixin should have a get_context_data() method
--+--
Reporter: akulakov | Owner: akulakov
Type: Cleanup/optimization | Status: new
Component: Generic views |Version: master
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Easy pickings: 0 | UI/UX: 0
--+--
Currently SingleObjectMixin and MultipleObjectMixin have get_context_data
but FormMixin does not, instead form is added to context via an argument
in get() method.

The reason for this is probably because it's just one line of code and it
did not seem to warrant a method.

However, it would be really nice to have this method for a few reasons:

1. consistency: FormView, UpdateView, CreateView context gets populated in
the same way as in DetailView and ListView. When GCBVs are customized,
users will know that context is populated in the same place for all views.

2. From the point of view of documentation, it's also easier because you
can tell users where context is created for all views rather than
specifying two different places, especially because you have to explain
that argument to get_context_data gets added to context.

3. Logically, it seems like it should belong to get_context_data(). A user
who is not closely familiar with GCBVs may be confused as to where context
comes from in Form Views. get_context_data() is an unambiguous location
for this logic as indicated by the name.

4. It makes it easier to combine different GCBVs. In case of FormView and
CreateView, you don't need to do anything in get() method (in CreateView
you may simply init self.object=None at class level), therefore when
combining these views with others, you can simply use get() methods from
the other View and let get_context_data() handle contexts of all inherited
views.

There are two alternatives: form initialization may be removed from get()
and post() methods OR it may be left there. In former case it may be a
backwards-incompatible change - although get_context_data() is supposed to
include a super() call to parent get_context_data() methods, users may
have it without the super() call, then form will disappear from context.

If form init is left in get()/post(), it's probably an acceptable
performance cost. Perhaps it can be left in but deprecated.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/051.0a97974cae0e1da7779d9245c8d03abf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24639: Interaction between ValidationError and mark_safe

2015-04-14 Thread Django

#24639: Interaction between ValidationError and mark_safe
+--
 Reporter:  jambonrose  |Owner:  jambonrose
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by hjwp):

 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8900145f48bea25da54fcf7fdb3c2ffb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24630: UUIDField migration

2015-04-14 Thread Django

#24630: UUIDField migration
-+-
 Reporter:  lucacorti|Owner:
 |  priidukull
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  uuidfiled| Triage Stage:
  migrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by priidukull):

 * status:  new => assigned
 * owner:  nobody => priidukull


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.4392994a2dd941a5fdd79b49c4971e89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14671: Allow overriding of ModelChoiceField.choices

2015-04-14 Thread Django

#14671: Allow overriding of ModelChoiceField.choices
---+
 Reporter:  simon29|Owner:  tbeadle
 Type:  Bug|   Status:  assigned
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sprintdec2010  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by tbeadle):

 * owner:  nobody => tbeadle
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6252768af0f58e655a8b033823df4ff8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24636: InvalidOperation saving decimal.Decimal

2015-04-14 Thread Django

#24636: InvalidOperation saving decimal.Decimal
-+-
 Reporter:  glic3rinu|Owner:
 |  iuliachiriac
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  InvalidOperation | Triage Stage:  Accepted
  decimal Decimal|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by iuliachiriac):

 * owner:  nobody => iuliachiriac
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0191ac753466e88ce5828fb317b8d45c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21652: Make ``loaddata`` notify about how many objects from fixture got processed

2015-04-14 Thread Django

#21652: Make ``loaddata`` notify about how many objects from fixture got 
processed
-+-
 Reporter:  while0pass   |Owner:  yitzc
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.9c53d12e821fd2b96442e07e78c6e9b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24605: Database identifiers are not properly escaped in some queries

2015-04-14 Thread Django

#24605: Database identifiers are not properly escaped in some queries
-+-
 Reporter:  kurevin  |Owner:
 |  priidukull
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  regression,  | Triage Stage:  Accepted
  database   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by priidukull):

 I have reproduced the issue by having added the following lines into the
 tests.queries module:

 tests.py:

 {{{
 class TestTicket24605(TestCase):
 def test_ticket_24605(self):
 results = Amodel.objects.exclude(bmodel__id=False,
 cmodel__isnull=True)
 self.assertEqual(0, len(results))
 }}}

 models.py:

 {{{
 class Bmodel(models.Model):
 id = models.AutoField(primary_key=True)
 is_active = models.BooleanField()

 class Meta:
 db_table = 'Bmodel'


 class Amodel(models.Model):
 active = models.BooleanField()
 bmodel = models.ForeignKey(Bmodel, related_name='Amodel_bmodel')

 class Meta:
 db_table = 'Amodel'


 class Cmodel(models.Model):
 amodel = models.ForeignKey(Amodel)

 class Meta:
 db_table = 'Cmodel'
 }}}

 However, the test does not fail every time it runs. I have run the test
 for 100 consecutive times twice. Passed 42 times the first time I ran it
 and 45 times the second time I ran it. Whether the test fails or passes
 depends on in which order the children of the Q-object are iterated over.
 The test fails if the order of {{{q_object.children}}} is:

 {{{('bmodel__id', False), ('cmodel__isnull', True) }}}

 and passes when the order is inverse.

 The order of q_object children is determined in the method
 {{{Q.__init__()}}}

 {{{super(Q, self).__init__(children=list(args) +
 list(six.iteritems(kwargs)))   }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f535fb285bf8d16209326bc48e079d1b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24424: Removing a model's last field results in SQL syntax error on SQLite

2015-04-14 Thread Django

Comment (by MarkusH):

Replying to [comment:21 jwineinger]:
> When you say "it is not about a DeleteModel operation following a
RemoveField. That could just remove that field", what do you mean?

If you have `RemoveField('mymodel', 'myfield')` followed by a
`DeleteModel('MyModel')` operation, I can't construct a case where Django
would end up constructing those two operations automatically where the
`RemoveField` would create a model without fields. A single `DeleteModel`
operation should be sufficient to drop the table and all its constraints.

> Should the approach be to change the auto-detector to not produce states
with zero columns, or should we try and handle that somewhere else?

Giving this issue more thoughts, I think the only way to prevent the
autodetector to construct states with models without fields is making the
`AlterField` operation smarter. Furthermore, when `RemoveField` would drop
the last field on a model, an `AlterField` operation must be used that
then can take care of the steps I outlined in [comment:20 comment 20].
This is only necessary for primary keys, though, I think. All other cases
can be fixed by first adding the new field and then removing the old
field.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.c76ddf095d84f9720068b5bf029f5404%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24370: Recommend that all new projects use a custom user model

2015-04-14 Thread Django

#24370: Recommend that all new projects use a custom user model
-+-
 Reporter:  carljm   |Owner:
 Type:   |  maestrofjp
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I think addressing #20629 would be a good start.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.dfb5aaa242eb6d5902bc5646456eb707%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24604: JSONField for contrib.postgres

2015-04-14 Thread Django

#24604: JSONField for contrib.postgres
--+
 Reporter:  mjtamlyn  |Owner:  mjtamlyn
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.64ac14a7bd8d4fb3e1f6b3611dbd6288%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24385: Sum() doesn't seem to respect .distinct() in the queryset filter before .aggregate() when filtering by m2m.

2015-04-14 Thread Django

#24385: Sum() doesn't seem to respect .distinct() in the queryset filter before
.aggregate() when filtering by m2m.
-+-
 Reporter:  mcagl|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks good, pending some comment cleanups and squashing of commits.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.28bd96de97aba3d55921838a06bac275%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24640: Add AbstractUser.get_display_name() (was: custom function for display name)

2015-04-14 Thread Django

#24640: Add AbstractUser.get_display_name()
--+--
 Reporter:  atmb4u|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

 * easy:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.6b77409b23debbd4a551fa22e7022764%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

2015-04-14 Thread Django

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
-+-
 Reporter:  Leo  |Owner:
 |  albertoconnor
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Leo):

 Thank you albertoconnor for putting this bug to rest!

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.f54b1ed343b7cde9dd772b7e259a329e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24277: Passing a dict with 2 keys to a queryset filter passes erroneously.

2015-04-14 Thread Django

#24277: Passing a dict with 2 keys to a queryset filter passes erroneously.
-+-
 Reporter:  kezabelle|Owner:
 Type:   |  alexandrinaw
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"99d40c6f658ead97f67d331eed9278805c8a4007" 99d40c6]:
 {{{
 #!CommitTicketReference repository=""
 revision="99d40c6f658ead97f67d331eed9278805c8a4007"
 Fixed #24277 -- Added exception when dict used in QuerySet filtering
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.9f47673b6aa86237903d6f9bb948e0fe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24424: Removing a model's last field results in SQL syntax error on SQLite

2015-04-14 Thread Django

Comment (by jwineinger):

I admit that wasn't the use case I was trying to fix. It seems that there
are multiple situation where migrations create states with zero columns in
a table. I don't see the relevance in what you describe to the problem I
was having, so perhaps they are separate symptoms of this same problem.

When you say "it is not about a DeleteModel operation following a
RemoveField. That could just remove that field", what do you mean?

Should the approach be to change the auto-detector to not produce states
with zero columns, or should we try and handle that somewhere else?

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.c693cd3736fd008ae5aaa0ead88c9b61%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23984: Document all available javascript_catalog's functions

2015-04-14 Thread Django

#23984: Document all available javascript_catalog's functions
--+
 Reporter:  bmispelon |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 Left some cosmetic comments.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0ec0ceed583c7fb7e44901660d9f0e6e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21221: Widgets and Admin's Media should use the configured staticfiles storage to create the right path to a file

2015-04-14 Thread Django

#21221: Widgets and Admin's Media should use the configured staticfiles storage 
to
create the right path to a file
-+-
 Reporter:  Guilherme Gondim |Owner:  antonpp
  |
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  staticfiles, admin,  | Triage Stage:  Accepted
  CachedFilesMixin, media, widgets   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by antonpp):

 * owner:  nobody => antonpp
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/097.4522dd5d20016044ca6dabcae4e66839%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23836: aggregate with a sliced queryset doesn't work with relations

2015-04-14 Thread Django

#23836: aggregate with a sliced queryset doesn't work with relations
-+-
 Reporter:  reinout  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 It would be nice to bisect to determine the commit where it was fixed to
 ensure that a sufficient test was added.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b3f638d0b7f10c919116c7eccee3bfa0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23836: aggregate with a sliced queryset doesn't work with relations

2015-04-14 Thread Django

#23836: aggregate with a sliced queryset doesn't work with relations
-+-
 Reporter:  reinout  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yitzc):

 * cc: yitzc (added)


Comment:

 Hi,
 The test from reinout's branch passes against the current master.
 Looking at the sql run in the aggregate function seems to properly join
 the relation, which allows completing the query successfully.
 I think it can be closed.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.65548b85b10520d261d8d22f9d39dea3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24635: New project provides deprecated examples

2015-04-14 Thread Django

#24635: New project provides deprecated examples
-+-
 Reporter:  jambonrose   |Owner:
 Type:   |  jambonrose
  Cleanup/optimization   |   Status:  closed
Component:  Core (Management |  Version:  1.8
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  startproject | Triage Stage:  Ready for
  templates  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"0b5abb03218ff0c575cee0c83e446bab81cbfadd" 0b5abb03]:
 {{{
 #!CommitTicketReference repository=""
 revision="0b5abb03218ff0c575cee0c83e446bab81cbfadd"
 Fixed #24635 -- Updated deprecated urls.py examples in default project
 template.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1385b5167dffe4bea170fb3aab887a93%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24635: New project provides deprecated examples

2015-04-14 Thread Django

#24635: New project provides deprecated examples
-+-
 Reporter:  jambonrose   |Owner:
 Type:   |  jambonrose
  Cleanup/optimization   |   Status:  closed
Component:  Core (Management |  Version:  1.8
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  startproject | Triage Stage:  Ready for
  templates  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"b1d83209d0a0df698e66d1cb5fa2a87b9859c3ed" b1d8320]:
 {{{
 #!CommitTicketReference repository=""
 revision="b1d83209d0a0df698e66d1cb5fa2a87b9859c3ed"
 [1.8.x] Fixed #24635 -- Updated deprecated urls.py examples in default
 project template.

 Backport of 0b5abb03218ff0c575cee0c83e446bab81cbfadd from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.99e40f6832be58563a750bfdb570ac7f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24603: Add the ability to use context.update() as a context manager

2015-04-14 Thread Django

#24603: Add the ability to use context.update() as a context manager
-+-
 Reporter:  cjerdonek|Owner:  tbeadle
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  template,context,push,update   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by cjerdonek):

 Wow, only six days -- thanks for adding this so quickly!

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b4ebaa12b00bdb93702f3b7fd4fe9fed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24385: Sum() doesn't seem to respect .distinct() in the queryset filter before .aggregate() when filtering by m2m.

2015-04-14 Thread Django

#24385: Sum() doesn't seem to respect .distinct() in the queryset filter before
.aggregate() when filtering by m2m.
-+-
 Reporter:  mcagl|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kutenai):

 * cc: kutenai (added)
 * has_patch:  0 => 1


Comment:

 Added a pull request with a test to validate this issue and insure it does
 not get re-introduced.

 https://github.com/django/django/pull/4507

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.223d24d483771034bdc7fa777cb64042%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11028: Problem with searching in m2m fields in inherited model

2015-04-14 Thread Django

#11028: Problem with searching in m2m fields in inherited model
-+-
 Reporter:  vitek_pliska |Owner:
 |  albertoconnor
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin search | Triage Stage:  Accepted
  inheritance|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by albertoconnor):

 bisecting showed that the issue was fixed in
 cf70c96ce08bec8834ada695451cc915f7558dbd.

 It isn't clear if there is a regression test in that commit, it is
 possible another test catches it though.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.696018e03ea3ba48ac97c8614e48d497%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11028: Problem with searching in m2m fields in inherited model

2015-04-14 Thread Django

#11028: Problem with searching in m2m fields in inherited model
-+-
 Reporter:  vitek_pliska |Owner:
 |  albertoconnor
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin search | Triage Stage:  Accepted
  inheritance|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by albertoconnor):

 * Attachment "test11028.diff" added.

 Patch to add a negative test case for bisecting

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.3f9ba160de084fb8185517a59f1dac9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24636: InvalidOperation saving decimal.Decimal

2015-04-14 Thread Django

#24636: InvalidOperation saving decimal.Decimal
-+-
 Reporter:  glic3rinu|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  InvalidOperation | Triage Stage:  Accepted
  decimal Decimal|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * Attachment "24636-test.diff" added.


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.93e940e947e0521933cd383247eba706%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24635: New project provides deprecated examples

2015-04-14 Thread Django

#24635: New project provides deprecated examples
-+-
 Reporter:  jambonrose   |Owner:
 Type:   |  jambonrose
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  1.8
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startproject | Triage Stage:  Ready for
  templates  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.998ee6e874fd477c01d813f78b980583%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23984: Document all available javascript_catalog's functions

2015-04-14 Thread Django

#23984: Document all available javascript_catalog's functions
--+
 Reporter:  bmispelon |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by dtran320):

 * owner:  dtran320 =>
 * status:  assigned => new


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f93a328c0c72c0a0f2e8f25a75af21e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23984: Document all available javascript_catalog's functions

2015-04-14 Thread Django

#23984: Document all available javascript_catalog's functions
--+
 Reporter:  bmispelon |Owner:  dtran320
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by daniellindsley):

 I put together a basic description of each function (as well as some
 examples). I've pushed what I've got to
 https://github.com/django/django/pull/4509 for
 review/corrections/expansions.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.902e907acf9088d28f08832d76a25b8f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24636: InvalidOperation saving decimal.Decimal

2015-04-14 Thread Django

#24636: InvalidOperation saving decimal.Decimal
-+-
 Reporter:  glic3rinu|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  InvalidOperation | Triage Stage:  Accepted
  decimal Decimal|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  closed => new
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 I didn't see the any reasoning why a `ValidationError` shouldn't be
 raised? Attached is the patch I used to reproduce the error.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a94275814efcff17040f6792c6b00183%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24636: InvalidOperation saving decimal.Decimal

2015-04-14 Thread Django

#24636: InvalidOperation saving decimal.Decimal
-+-
 Reporter:  glic3rinu|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  InvalidOperation | Triage Stage:
  decimal Decimal|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by iuliachiriac):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 This is not actually a bug.
 `value=1` with 2 decimals will be saved as `1.00`, meaning it exceeds the
 maximum number of digits (you actually have 3 digits). In general, if
 `max_digits == decimal_places` you can only save subunitary numbers, with
 a precision of `decimal_places` digits.
 Similarly, `max_digits=3` and `decimal_places=1` will work for numbers up
 to `9.99`, and will fail for `value=11`.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.55b0c22c1cc9f0cf581a85fbc1bbc608%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24277: Passing a dict with 2 keys to a queryset filter passes erroneously.

2015-04-14 Thread Django

#24277: Passing a dict with 2 keys to a queryset filter passes erroneously.
-+-
 Reporter:  kezabelle|Owner:
 Type:   |  alexandrinaw
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by alexandrinaw):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.12963fb1c796bbaf9b227145212b66cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11028: Problem with searching in m2m fields in inherited model

2015-04-14 Thread Django

#11028: Problem with searching in m2m fields in inherited model
-+-
 Reporter:  vitek_pliska |Owner:
 |  albertoconnor
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin search | Triage Stage:  Accepted
  inheritance|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by albertoconnor):

 * owner:  nobody => albertoconnor
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.247d3a6b2e981933236819f6a7a42d5f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24637: get_constraints broke on newer version of sqlite.

2015-04-14 Thread Django

#24637: get_constraints broke on newer version of sqlite.
-+-
 Reporter:  dmrsearch|Owner:
 |  maestrofjp
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"309142dba10e24557b67a2734aa67d56518c0b14" 309142d]:
 {{{
 #!CommitTicketReference repository=""
 revision="309142dba10e24557b67a2734aa67d56518c0b14"
 [1.8.x] Fixed #24637 -- Fixed database introspection with SQLite 3.8.9.

 Backport of f8e8853b51476af1cc75a229dadc990c9ccf45ec from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7dd18f21f95c606636d95ce360590588%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24637: get_constraints broke on newer version of sqlite.

2015-04-14 Thread Django

#24637: get_constraints broke on newer version of sqlite.
-+-
 Reporter:  dmrsearch|Owner:
 |  maestrofjp
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"d74903e4fb381576e5cb0cbfbd19555bcd255752" d74903e4]:
 {{{
 #!CommitTicketReference repository=""
 revision="d74903e4fb381576e5cb0cbfbd19555bcd255752"
 [1.7.x] Fixed #24637 -- Fixed database introspection with SQLite 3.8.9.

 Backport of f8e8853b51476af1cc75a229dadc990c9ccf45ec from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c13bf346e906370e52a33d959fdd1a05%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24637: get_constraints broke on newer version of sqlite.

2015-04-14 Thread Django

#24637: get_constraints broke on newer version of sqlite.
-+-
 Reporter:  dmrsearch|Owner:
 |  maestrofjp
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"f8e8853b51476af1cc75a229dadc990c9ccf45ec" f8e8853]:
 {{{
 #!CommitTicketReference repository=""
 revision="f8e8853b51476af1cc75a229dadc990c9ccf45ec"
 Fixed #24637 -- Fixed database introspection with SQLite 3.8.9.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.3be8363a62f00f89a6b306cca105d3b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24370: Recommend that all new projects use a custom user model

2015-04-14 Thread Django

* owner: nobody => maestrofjp
* status: new => assigned

Comment:

I'd like to help out by making the documentation change to reflect
whatever is decided. I'm assigning myself this ticket -- feel to steal it
back.

I agree @timgraham that modifying the default project template appears to
be way beyond the scope of this ticket. I think a good first step would be
massage the wording around this.

I'm relatively new Django developer (just a couple years) and the wording
around this is very scary. I originally was dissuaded from using a custom
user model, luckily we migrated to one before the application went to
production. However, the transition was still painful as all of our
migrations changed, etc.

If a consensus can be made, I'm happy to update the documentation. Please
advise next steps...

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.383b437f9d023698ef61da710f20e3d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

2015-04-14 Thread Django

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
-+-
 Reporter:  Leo  |Owner:
 |  albertoconnor
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by albertoconnor):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 After bisecting I discovered commit
 9e04c3b7444ba136efa03896a67e46d2e7045e28 which fixes the issue and does
 add a test which seems tests the issue raised in this bug.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.6e6f2c1034811a7fa993956c3f16f6c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24642: If queryset has orderby before distinct query selects the orderby

2015-04-14 Thread Django

#24642: If queryset has orderby before distinct query selects the orderby
-+-
 Reporter:  ark4n631 |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 This is a documented behavior, please see the first note box under the
 
[https://docs.djangoproject.com/en/1.8/ref/models/querysets/#django.db.models.query.QuerySet.distinct
 distinct() documentation].

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.76355083eea9097a1532677fccc04d11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24642: If queryset has orderby before distinct query selects the orderby

2015-04-14 Thread Django

#24642: If queryset has orderby before distinct query selects the orderby
-+-
 Reporter:  ark4n631 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> If you generate a query set like:
> [[BR]]
> orders = Order.objects.filter( date = paramDate, objfilter =
> paramObjfilter ).order_by( 'date' )
> dudes  = orders.values('dude').distinct().exclude(dude__isnull = True)
> [[BR]]
> [[BR]]
>
> Query will be:
> [[BR]]
> SELECT DISTINCT "base_ordentrabajo"."dude_id", "base_orders"."date" FROM
> "base_orders" WHERE ...
> [[BR]]
> If you remove order_by and make distinct after query is quite different
> (and like should be)
> [[BR]]
> orders = Order.objects.filter( date = paramDate, objfilter =
> paramObjfilter )
> dudes  = orders.values('dude').distinct().exclude(dude__isnull = True)
> [[BR]]
> SELECT DISTINCT "base_ordentrabajo"."dude_id" FROM "base_orders" WHERE
> ...
> [[BR]]
> So i can't make an order_by if i need to make a distinct first. Anyway
> django should warn of query.order_by or don't allow to make a subset
> query filter with distinct if you order in the first place because this
> lead to unexpected results on query (query will contain not distinct
> values for the field you are searching for because it adds the order_by
> field value to the query)

New description:

 If you generate a query set like:
 {{{
 orders = Order.objects.filter( date = paramDate, objfilter =
 paramObjfilter ).order_by( 'date' )
 dudes  = orders.values('dude').distinct().exclude(dude__isnull = True)
 }}}

 Query will be:
 {{{
 SELECT DISTINCT "base_ordentrabajo"."dude_id", "base_orders"."date" FROM
 "base_orders" WHERE ...
 }}}
 If you remove order_by and make distinct after query is quite different
 (and like should be)
 {{{
 orders = Order.objects.filter( date = paramDate, objfilter =
 paramObjfilter )
 dudes  = orders.values('dude').distinct().exclude(dude__isnull = True)

 SELECT DISTINCT "base_ordentrabajo"."dude_id" FROM "base_orders" WHERE ...
 }}}
 So i can't make an order_by if i need to make a distinct first. Anyway
 django should warn of query.order_by or don't allow to make a subset query
 filter with distinct if you order in the first place because this lead to
 unexpected results on query (query will contain not distinct values for
 the field you are searching for because it adds the order_by field value
 to the query)

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.5709123dabc59a1e1f2af2c749689b50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24642: If queryset has orderby before distinct query selects the orderby

2015-04-14 Thread Django

#24642: If queryset has orderby before distinct query selects the orderby
--+
 Reporter:  ark4n631  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 If you generate a query set like:
 [[BR]]
 orders = Order.objects.filter( date = paramDate, objfilter =
 paramObjfilter ).order_by( 'date' )
 dudes  = orders.values('dude').distinct().exclude(dude__isnull = True)
 [[BR]]
 [[BR]]

 Query will be:
 [[BR]]
 SELECT DISTINCT "base_ordentrabajo"."dude_id", "base_orders"."date" FROM
 "base_orders" WHERE ...
 [[BR]]
 If you remove order_by and make distinct after query is quite different
 (and like should be)
 [[BR]]
 orders = Order.objects.filter( date = paramDate, objfilter =
 paramObjfilter )
 dudes  = orders.values('dude').distinct().exclude(dude__isnull = True)
 [[BR]]
 SELECT DISTINCT "base_ordentrabajo"."dude_id" FROM "base_orders" WHERE ...
 [[BR]]
 So i can't make an order_by if i need to make a distinct first. Anyway
 django should warn of query.order_by or don't allow to make a subset query
 filter with distinct if you order in the first place because this lead to
 unexpected results on query (query will contain not distinct values for
 the field you are searching for because it adds the order_by field value
 to the query)

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.2ff07b3c4e4b6b26a595e8fd9175d91b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24638: New feature: support adding an SQL comment in queries

2015-04-14 Thread Django

#24638: New feature: support adding an SQL comment in queries
-+-
 Reporter:  adamchainz   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, query, | Triage Stage:  Accepted
  comment, optimizer hint|
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_docs:  0 => 1
 * has_patch:  0 => 1


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.4554f92fd900791ba1da1801c557065d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21144: Not possible to update foreign key by id for a queryset

2015-04-14 Thread Django

#21144: Not possible to update foreign key by id for a queryset
-+-
 Reporter:  dakinsloss@… |Owner:  vaskalas
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  update, related  | Triage Stage:  Accepted
  model, performance |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vaskalas):

 The unit test was added actually added in this commit,
 
https://github.com/django/django/commit/e01b5a5823fa06a63382f87472978a16c77048d2

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.7c1048c05a8ff3213a665e5a917ac1fe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24638: New feature: support adding an SQL comment in queries

2015-04-14 Thread Django

#24638: New feature: support adding an SQL comment in queries
-+-
 Reporter:  adamchainz   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, query, | Triage Stage:  Accepted
  comment, optimizer hint|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.71d66fb60aae21bf6330bedb58f93883%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24641: ZIP archive with HTML documentation is empty

2015-04-14 Thread Django

#24641: ZIP archive with HTML documentation is empty
---+--
 Reporter:  gim-   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Duplicate of https://github.com/django/djangoproject.com/issues/447

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.9b2a185f3ef5957a5a748b6700349246%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24640: custom function for display name

2015-04-14 Thread Django

#24640: custom function for display name
--+--
 Reporter:  atmb4u|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Adding my thought from the pull request: "If Django doesn't use the
 method, I tend to think it's better suited to leave it to custom user
 models."

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.627be621a8973b2de8291e4d5099de87%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24638: New feature: support adding an SQL comment in queries

2015-04-14 Thread Django

#24638: New feature: support adding an SQL comment in queries
-+-
 Reporter:  adamchainz   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset, query, | Triage Stage:
  comment, optimizer hint|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by stevemcc):

 * type:  Uncategorized => New feature


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.6e32ab0b1abfb0bb520ea763849c3926%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #8936: add databrowse-like functionality to the admin

2015-04-14 Thread Django

* cc: PetrDlouhy (added)
* needs_better_patch: 0 => 1
* has_patch: 0 => 1

Comment:

Hello,

I have added few corrections to my patch, fixed tests, added new tests and
made few updates to the documentation. I don't think, that all issues
connected with this are solved yet. Anyway, I would like my work to be
reviewed.

The new patches are part of (yet uncreated) pull request:

https://github.com/django/django/compare/master...PetrDlouhy:view_permission_master?expand=1

There few weak spots, that I am feeling that should be discussed with
someone more experienced:
* Model situation: User has defined `ModelAdmin` with custom
`has_change_permission()` such that it disallows to change (consequently
also view) anything.
* Then adding view permissions allows superuser to view that
`ModelAdmin`.
* I had to change `RowLevelChangePermissionModelAdmin` in tests for this.
* How should change `RelatedFieldWidgetWrapper`

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.326e2f21737b53a49d0e65182c094f2d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24641: ZIP archive with HTML documentation is empty

2015-04-14 Thread Django

#24641: ZIP archive with HTML documentation is empty
---+
 Reporter:  gim-   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 https://docs.djangoproject.com/m/docs/django-docs-1.8-en.zip
 {{{
 % du -sh django-docs-1.8-en.zip
 8.0Kdjango-docs-1.8-en.zip

 % unzip -l django-docs-1.8-en.zip
 Archive:  django-docs-1.8-en.zip
 warning [django-docs-1.8-en.zip]:  zipfile is empty
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.6d7deffbd2df0ee358ec0b80cd4a111e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24640: custom function for display name

2015-04-14 Thread Django

#24640: custom function for display name
--+
 Reporter:  atmb4u|  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+
 Most of the time, get_full_name() returns only first name and last name,
 and many a times, if first name and last name is not present, we need at
 least the email or the username to be returned to the template.
 get_display_name() returns the email if there is no get_full_name(); and
 if no email, then fallback to username. I find get_display_name more
 pragmatic than the proposed get_full_name, when it comes to showing user
 details in templates.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.70a8ba1be5ef07cd7efb992c6e60dbeb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

2015-04-14 Thread Django

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
-+-
 Reporter:  Leo  |Owner:
 |  albertoconnor
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by albertoconnor):

 Thanks tim, will do.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.b693ec9447fba672e7fee092b21435d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20516: Allow use of prepared statements

2015-04-14 Thread Django

#20516: Allow use of prepared statements
-+-
 Reporter:  est  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db, prepared | Triage Stage:  Accepted
  statement  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by thedrow):

 akaariai says we can just subclass the Query object and replace the
 parameters with the prepared statements placeholders.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.31f16b03c5a6a86023f3d110a73c8608%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

2015-04-14 Thread Django

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
-+-
 Reporter:  Leo  |Owner:
 |  albertoconnor
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 albertoconnor, just wanted to suggest to use git bisect to find the commit
 where this was fixed to see what tests were added there (to prevent adding
 duplicate tests).

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.751a72cc18f4e135b850bb8fb845a548%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16609: Admin searches produce duplicate results if search_fields contains M2M traversals

2015-04-14 Thread Django

#16609: Admin searches produce duplicate results if search_fields contains M2M
traversals
-+-
 Reporter:  cheater00@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  search_fields m2m| Triage Stage:  Accepted
  duplicate duplicates   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 I wonder if we might mark this as a duplicate of #15819. The proposed
 patch there removes `lookup_needs_distinct()` instead of making it more
 complicated and looks like it would fix other issues.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.25b98f1eaa7b7094f72a3099a094%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20516: Allow use of prepared statements

2015-04-14 Thread Django

#20516: Allow use of prepared statements
-+-
 Reporter:  est  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db, prepared | Triage Stage:  Accepted
  statement  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by thedrow):

 As apollo13 mentioned on IRC, prepared statements are at the session level
 on PostgresSQL so we can just store them on the connection object.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.bd07c5110e0b1b680bdce3178cea8a3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24603: Add the ability to use context.update() as a context manager

2015-04-14 Thread Django

#24603: Add the ability to use context.update() as a context manager
-+-
 Reporter:  cjerdonek|Owner:  tbeadle
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  template,context,push,update   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"6bfd864ff2a7d4903d485ee40094a1315da8221b" 6bfd864]:
 {{{
 #!CommitTicketReference repository=""
 revision="6bfd864ff2a7d4903d485ee40094a1315da8221b"
 Fixed #24603 -- Allowed Context.update() to be used as a context manager.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6559ac657a74b12b7e365750ca7dfde6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24603: Add the ability to use context.update() as a context manager

2015-04-14 Thread Django

#24603: Add the ability to use context.update() as a context manager
-+-
 Reporter:  cjerdonek|Owner:  tbeadle
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  template,context,push,update   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.76b4e2a12b113a01e0baf7d929d30b5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24277: Passing a dict with 2 keys to a queryset filter passes erroneously.

2015-04-14 Thread Django

#24277: Passing a dict with 2 keys to a queryset filter passes erroneously.
-+-
 Reporter:  kezabelle|Owner:
 Type:   |  alexandrinaw
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left minor comments for improvement.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.cb2013d2f55ac91b732e828530c270d6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16609: Admin searches produce duplicate results if search_fields contains M2M traversals

2015-04-14 Thread Django

#16609: Admin searches produce duplicate results if search_fields contains M2M
traversals
-+-
 Reporter:  cheater00@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  search_fields m2m| Triage Stage:  Accepted
  duplicate duplicates   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by sampaccoud):

 I came across this bug which does not seem to be totally fixed yet? I
 tried to propose a fix and submitted a PR:
 https://github.com/django/django/pull/4504

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.bcf10935a34a3bd4691cc2d548f67534%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16609: Admin searches produce duplicate results if search_fields contains M2M traversals

2015-04-14 Thread Django

#16609: Admin searches produce duplicate results if search_fields contains M2M
traversals
-+-
 Reporter:  cheater00@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  search_fields m2m| Triage Stage:  Accepted
  duplicate duplicates   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sampaccoud):

 * status:  closed => new
 * resolution:  fixed =>


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.f6c7b328166b9e5966c8041863683852%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #12199: Give 'firstof' tag ability to assign result to context

2015-04-14 Thread Django

#12199: Give 'firstof' tag ability to assign result to context
--+
 Reporter:  tiliv |Owner:  craigls
 Type:  New feature   |   Status:  closed
Component:  Template system   |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  firstof, as, context  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"75bc5bc634e90d5ccd2d7fc324df878dc5d4ce5d" 75bc5bc6]:
 {{{
 #!CommitTicketReference repository=""
 revision="75bc5bc634e90d5ccd2d7fc324df878dc5d4ce5d"
 Fixed #12199 -- Added the ability to use "as" with the firstof template
 tag.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.4db55a46618d06ba56a2df30ef9566e5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24625: Arbitrary file inclusion in admindocs

2015-04-14 Thread Django

#24625: Arbitrary file inclusion in admindocs
-+-
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  Bug  |   Status:  closed
Component:  contrib.admindocs|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Holtermann ):

 In [changeset:"584c6591a3c29c94026e3bebc3e5302a3d7530e3" 584c6591]:
 {{{
 #!CommitTicketReference repository=""
 revision="584c6591a3c29c94026e3bebc3e5302a3d7530e3"
 [1.8.x] Refs #24625 -- Filtered docutils warnings output in tests

 Instead of setting ``warning_stream`` in the docutils config overrides
 to ``False`` I opted for filtering the stderr in the tests to keep the
 error output showing up in server logs.

 Thanks Tim Graham for the report and review

 Backport of 3caf7efb44712f89d6552076c240a3c898673a2c from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.387e4ff7baad8c044215e8b6831fa84a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24625: Arbitrary file inclusion in admindocs

2015-04-14 Thread Django

#24625: Arbitrary file inclusion in admindocs
-+-
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  Bug  |   Status:  closed
Component:  contrib.admindocs|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markus Holtermann ):

 In [changeset:"3caf7efb44712f89d6552076c240a3c898673a2c" 3caf7efb]:
 {{{
 #!CommitTicketReference repository=""
 revision="3caf7efb44712f89d6552076c240a3c898673a2c"
 Refs #24625 -- Filtered docutils warnings output in tests

 Instead of setting ``warning_stream`` in the docutils config overrides
 to ``False`` I opted for filtering the stderr in the tests to keep the
 error output showing up in server logs.

 Thanks Tim Graham for the report and review
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b1890a896f529c37278591b7af8f65a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24595: alter field type on MySQL "forgets" nullability (and more)

2015-04-14 Thread Django

#24595: alter field type on MySQL "forgets" nullability (and more)
-+
 Reporter:  simonpercivall   |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * owner:  claudep =>
 * status:  assigned => new
 * has_patch:  0 => 1


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.571c39534ff2fb59ed4a12544263b629%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

86 matches

Mail list logo