Re: [Django] #26256: JSON serializer for subset of fields. (was: JSON serializer is not working for subset of fields.)

[Django]

#26256: JSON serializer for subset of fields.
-+-
 Reporter:  sonus21  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core |  Version:  1.8
  (Serialization)|
 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 sonus21):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 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/065.c4d037d987aac1d87471bdb92e8ff896%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26256: JSON serializer is not working for subset of fields.

[Django]

#26256: JSON serializer is not working for subset of fields.
--+
 Reporter:  sonus21   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Core (Serialization)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 {{{
 class Country(models.Model):
 country = CountryField()

 class City(models.Model):
 name = models.CharField(max_length=1000)
 country = models.ForeignKey(Country)

 country = request.POST['country']
 country = get_object_or_404(Country, country=country)
 cities = serializers.serialize("json", country.city_set.all(),
 fields=('name', 'id'))
 }}}

 [https://docs.djangoproject.com/en/1.8/topics/serialization/#s-subset-of-
 fields]

 According to above code snippet and document it should return JSON object
 with only name and id field but it returns
 {{{
 [{"fields": {"name": "Chennai"}, "model": "job.city", "pk": 1}]
 }}}
 instead of
 {{{
 [{"name": "Chennai", "id": 1}]
 }}}
 which includes all fields of a model City.

--
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/050.c7aacb93aaf7f36256b0ee13402e85df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

[Django]

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jbrendel):

 Thank you for looking into this. So, is that a Django bug? Is this
 something I can work around via particular settings?

--
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/074.f2b06b843f61fc213d9a1e1c898183c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

[Django]

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 I see, the code that makes sure to create a default site assumes that the
 `Site`'s table exist after each `migrate` even if the migrations to apply
 were restricted to a subset that don't include the initial `sites`
 migration.

--
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/074.d2e9a1ef783969ed7de1b7df2481b389%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

[Django]

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jbrendel):

 * cc: django@… (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/074.f48364b8746d37e86f54f47bfbfaf2ef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

[Django]

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jbrendel):

 Hello!

 Here is the full traceback:

 {{{
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/core/management/__init__.py", line 354, in
 execute_from_command_line
 utility.execute()
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/core/management/__init__.py", line 346, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/core/management/base.py", line 394, in run_from_argv
 self.execute(*args, **cmd_options)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/core/management/base.py", line 445, in execute
 output = self.handle(*args, **options)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/core/management/commands/migrate.py", line 226, in
 handle
 emit_post_migrate_signal(created_models, self.verbosity,
 self.interactive, connection.alias)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/core/management/sql.py", line 280, in
 emit_post_migrate_signal
 using=db)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/dispatch/dispatcher.py", line 189, in send
 response = receiver(signal=self, sender=sender, **named)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/contrib/sites/management.py", line 20, in
 create_default_site
 if not Site.objects.using(using).exists():
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/models/query.py", line 586, in exists
 return self.query.has_results(using=self.db)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/models/sql/query.py", line 484, in has_results
 return compiler.has_results()
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/models/sql/compiler.py", line 811, in has_results
 return bool(self.execute_sql(SINGLE))
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/models/sql/compiler.py", line 840, in execute_sql
 cursor.execute(sql, params)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/utils.py", line 98, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File
 "/home/jbrendel/projects/zzyyxx/repo/zzyyxx_test2/local/lib/python2.7
 /site-packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: relation "django_site" does not exist
 LINE 1: SELECT (1) AS "a" FROM "django_site" LIMIT 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 

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

[Django]

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Hi jbrendel,

 From your report I suspect your issue has little to do with migrations.

 Is it possible to provide the full traceback of the `ProgrammingError`?

--
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/074.ffcbcee2f8e3e6cc09110c8c1618345e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it

[Django]

#24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it
-+-
 Reporter:  ssjunior |Owner:  ssjunior
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 This patch has only be merged in the ''master'' branch so far and is not
 part of any official release. It should be part of the upcoming 1.10
 release.

--
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.0ef6e6e033ef6d6e4fd2088f85d0e990%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

[Django]

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jbrendel):

 I have the same problem, but the suggested solution does not work for me,
 unfortunately.

 Specifically, it's a 1.7.6 application (backed by Postgres), which I would
 like to update to 1.8.9. I'm currently happy to completely reset the
 database, so there are no changes, I just need the initial schema
 creation. There are NO migrations in any of my apps, so no 'migrations'
 folders exist anywhere.

 I also have a custom user model (inheriting from 'AbstractUser'). When I
 do as suggested (`python manage.py makemigrations `), some
 migrations are created (even though there is no DB that might require
 migrations), but the subsequent 'migrate' still fails.

 Needless to say, this worked well for me on 1.7.6, but I'm now completely
 stuck with 1.8.9.

 One additional bit of information:

 I can get the migrations to finally run through with the following hacky
 procedure:

 1. `python manage.py makemigrations `.
 2. `python manage.py migrate `. This ends
 with `django.db.utils.ProgrammingError: relation "django_site" does not
 exist`, but we'll continue anyway...
 3. `python manage.py migrate`. Runs through without error. I need to make
 sure to have 'sites' listed before 'contentype' in my settings file.

 During step (2) a few tables are created, even though it eventually fails.
 Specifically, the "contenttypes" and "auth" related tables. This is
 important, since without "contenttypes" I can't migrate sites and without
 auth I can't migrate contenttypes. The only way I found to create those
 tables is by running a failed migration attempt for my app. There doesn't
 seem to be a way to create those tables in a way that doesn't result in an
 error at some point, due to what appears to be some sort of circular
 dependency between sites, contentypes and auth.

 Of course, such a hacky work-around is not really useful, since the test-
 database can't be created in that manner (its automated creation needs to
 work without hack).

 It seems I at least need to get this to the stage where I can just run
 `python manage.py migrate` (or `syncdb` for that matter, which also fails
 since it needs my app with the custom user model). Any help or insight
 would be greatly appreciated.

 Thank you very much!

--
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/074.1a1f0fcedae037ee56799769c9fbd14a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it

[Django]

#24675: Skip "SET SQL_AUTO_IS_NULL = 0" on versions of MySQL that don't need it
-+-
 Reporter:  ssjunior |Owner:  ssjunior
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by brianwawok):

 In development I still see 2 queries per page load for this. I assume
 because connections do not persist in dev.

 Seems this needs dealt with in a different way in dev?

--
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.1f93fae0faea2f7462d2c57441449cf8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26248: Make current WSGI request instance available in forms.ModelForm instances.

[Django]

#26248: Make current WSGI request instance available in forms.ModelForm 
instances.
+--
 Reporter:  Dmitri-Sintsov  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by aaugustin):

 You could certainly use a modelform without a request, for example to
 validate data pulled from a CSV file before inserting it into the
 database.

 It's unclear to me why you need to pass a request to a modelform so often.
 For me the frontier is materialized by `form = MyModelForm(request.POST)`.

 While it's true that (model)forms are usually closer to request handling
 than models, I'm not convinced coupling (model)forms to HTTP requests is
 justified.

--
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.1441b1757a765470cfc0149934dccfb1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14891: use_for_related_fields=False is not honored by reverse FK or M2M related managers

[Django]

#14891: use_for_related_fields=False is not honored by reverse FK or M2M related
managers
-+-
 Reporter:  sdksho@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Manager  | Triage Stage:  Accepted
  ManyToManyField|
  use_for_related_fields |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by loic):

 I like the `(manager='objects', related_manager='related')` API since it
 allows fine grained control over the relation manager as expected by the
 relational field. It's in the same spirit as
 https://docs.djangoproject.com/en/1.9/topics/db/queries/#using-a-custom-
 reverse-manager which allows controlling the reverse manager per query per
 relational field.

 But I also see merit in allowing the model to say which manager should be
 used by default by relations. My work on #20932 can easily be extended to
 support a `related_manager_name` meta.

 It would work as follows:
 {{{
 class Model(models.Model):
 objects = models.Manager()
 custom_manager = CustomManager()

 class Meta:
 related_manager_name = 'custom_manager'
 }}}

 PR https://github.com/django/django/pull/6175 shows a working
 implementation + deprecation.

--
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/076.dbee7d6dfd09170abf94e9f33797fac2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26248: Make current WSGI request instance available in forms.ModelForm instances.

[Django]

#26248: Make current WSGI request instance available in forms.ModelForm 
instances.
+--
 Reporter:  Dmitri-Sintsov  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Dmitri-Sintsov):

 Having request instance available everywhere (including model instances)
 is a bad design, encouraging misuse of models which might live in
 management commands without request at all. Having request in ModelForm
 instances and maybe in field widgets instance is a very useful thing and
 is a much less bad design.

 But as you wish.

--
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.ca4c115eeed4f61c39fc3e3f495b3efa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26238: confusing error message: django.core.exceptions.FieldError: Unknown field(s) specified when including a BinaryField in ModelForm.Meta.fields

[Django]

#26238: confusing error message: django.core.exceptions.FieldError: Unknown
field(s) specified when including a BinaryField in ModelForm.Meta.fields
-+-
 Reporter:  groovecoder  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 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 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/069.a0a7611cb5691a15d60ef4bc9fdebd6a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26255: In "Writing your first Django app, part 3" in "Writing more views" section it's not clear what include() refers to

[Django]

#26255: In "Writing your first Django app, part 3" in "Writing more views" 
section
it's not clear what include() refers to
--+
 Reporter:  ameidatou |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 In "Writing your first Django app, part 3" in "Writing more views" section
 in this sentence "The include() functions we are using simply reference
 other URLconfs"
 it's not clear what "include() functions" refers to?

--
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/052.fbb34c7374b177ca7f5a280e1aa306e4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26244: URLValidator and http/request.py use different validators

[Django]

#26244: URLValidator and http/request.py use different validators
-+-
 Reporter:  zachborboa   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  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
-+-

Comment (by apollo13):

 I do not see big wins in changing it and am worried that it becomes a
 nightmare like we have with host_re. Simple & easy is preferable in those
 code paths imo.

--
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.ead3d66d9b2e8d125adb0585829077cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26254: Support for disallowing filter on local fields in ModelAdmin

[Django]

#26254: Support for disallowing filter on local fields in ModelAdmin
--+
 Reporter:  DheerendraRathor  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.admin |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently, if a local field is not present in `list_filter` and filter is
 called on that particular field directly in URL, it is allowed to filter
 on that particular field. But, if filter is called on a relational field
 which is not present in `list_filter`, filter is disallowed on that
 particular field.

 This feature request is in support for disallowing filter on certain
 fields. This can be done by either not allowing filter on a field if field
 is not mentioned in `list_filter` or by adding an extra ModelAdmin field
 `disallowed_lookups`.  But disallowing on the basis of list_filter might
 break admin for sites heavily relying on admin, second option will be
 better in my opinion.


 {{{
 # An example fix
 if len(relation_parts) <= 1:
 # Either a local field filter, or no fields at all.
 if len(relation_parts) == 1 and relation_parts[0] in
 self.disallowed_lookups:
 return False
 return 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/059.5f16064725e5c7d30f974fb207f2e753%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25759: Add **kwargs to as_sql method of Expressions

[Django]

#25759: Add **kwargs to as_sql method of Expressions
-+-
 Reporter:  jarshwah |Owner:
 |  kaifeldhoff
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  expressions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by kaifeldhoff):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * needs_docs:  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/066.c680eaf7e048e4e77b461d7f4aad6ba2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.