Re: [Django] #6767: Oracle backend treats DecimalFields as floats somewhere, losing precision

[Django]

#6767: Oracle backend treats DecimalFields as floats somewhere, losing precision
-+-
   Reporter:  Matt Boersma   |Owner:  nobody
   Type: |   Status:  closed
  Component:  Database layer |  Version:  master
  (models, ORM)  |
   Severity: |   Resolution:  fixed
   Keywords:  oracle Oracle decimal  | Triage Stage:  Accepted
  float precision|
  Has patch:  0  |  Needs documentation:  0
Needs tests:  0  |  Patch needs improvement:  0
-+-

Comment (by GitHub ):

 In [changeset:"f32ee6d0ec31580cd1ab55e64ff4fb2122aba420" f32ee6d]:
 {{{
 #!CommitTicketReference repository=""
 revision="f32ee6d0ec31580cd1ab55e64ff4fb2122aba420"
 Refs #6767 -- Added test for fetching decimal values without rounding
 error on Oracle.
 }}}

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => 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/069.6d5200db82627d5570b19e46c3e9f884%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28145: Django documention - MySQL database connector - PyMySQL for python 3 support

[Django]

#28145: Django documention - MySQL database connector -  PyMySQL for python 3
support
---+--
 Reporter:  kinganu|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  mysql  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 We're recommending the
 [https://docs.djangoproject.com/en/dev/ref/databases/#mysql-db-api-drivers
 mysqlclient] MySQLdb fork. Is there a reason to prefer PyMySQL instead?

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

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  Alexander Artemenko  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |
  subclass   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Soheil Damangir):

 A quick fix without a need to patch could be to override the save method
 for the parent mode:

 {{{
  from django.db import models

  class MyModel(models.Model):
 """
 >>> m = MyModel(name="The model")
 >>> m.save()
 Hello!
 """
 name = models.CharField(max_length=10)
 def save(self, *args, **kwargs):
 # To trigger the signals for parent model
 klass = self.__class__
 try:
 if self.__class__._meta.proxy:
 self.__class__ = self.__class__._meta.concrete_model
 super(MyModel, self).save(*args, **kwargs)
 finally:
 self.__class__ = klass

  class ProxyModel(MyModel):
 """
 >>> p = ProxyModel(name="Proxy")
 >>> p.save()
 Hello!
 """
 class Meta:
 proxy = True


  from django.db.models.signals import post_save

  def say_hello(sender, *args, **kwargs):
  print "Hello!"
  post_save.connect(say_hello, sender=Parent)
 }}}

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

[Django] #28146: PostGIS: Django 1.11 adds two extra queries: SELECT postgis_lib_version() and SELECT version()

[Django]

#28146: PostGIS: Django 1.11 adds two extra queries: SELECT 
postgis_lib_version()
and SELECT version()
---+
   Reporter:  George Tantiras  |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  Uncategorized|Version:  1.11
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 * Python 3.4.2
 * PostgreSQL(9.4.10)
 * Database Extensions:
 {{{
  List of installed extensions
   Name   | Version |   Schema   | Description
 
-+-++-
  plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
  postgis | 2.1.4   | public | PostGIS geometry, geography, and raster
 spatial types and functions
 (2 rows)
 }}}

 models.py
 {{{
 from django.contrib.gis.db import models

 class TheModel(models.Model):
 polygon_area = models.PolygonField()
 centroid = models.PointField(srid=4326)
 }}}

 The code needed to fetch the results:
 {{{
 >>> from my.models import TheModel
 >>> from django.contrib.gis.geos import Point
 >>> from django.contrib.gis.measure import D
 >>> from django.contrib.gis.db.models.functions import Distance

 >>> db.reset_queries()
 >>> TheModel.objects.filter(centroid__distance_lte=(Point(23.12, 37.9),
 D(m=3000))).annotate(distance=Distance('centroid', Point(23.12,
 37.9))).order_by('polygon_area'))
  ... 
 >>> print(db.connection.queries)
 }}}
 Django-1.11 result(4 Queries, total time 0.025):
 {{{
 {'time': '0.003', 'sql': 'SELECT "spatial_ref_sys"."srid",
 "spatial_ref_sys"."auth_name", "spatial_ref_sys"."auth_srid",
 "spatial_ref_sys"."srtext", "spatial_ref_sys"."proj4text" FROM
 "spatial_ref_sys" WHERE "spatial_ref_sys"."srid" = 4326'}
 {'time': '0.001', 'sql': 'SELECT version()'}
 {'time': '0.014', 'sql': 'SELECT postgis_lib_version()'}
 {'time': '0.007', 'sql': 'SELECT "my_themodel"."id",
 "my_themodel"."polygon_area", "my_themodel"."centroid",
 ST_distance_sphere("my_themodel"."centroid",
 
ST_GeomFromEWKB(\'\\x010120e6101f85eb51b81e374033f34240\'::bytea))
 AS "distance" FROM "my_themodel" WHERE
 ST_distance_sphere("my_themodel"."centroid",
 
ST_GeomFromEWKB(\'\\x010120e6101f85eb51b81e374033f34240\'::bytea))
 <= 3000.0 ORDER BY "my_themodel"."polygon_area" ASC LIMIT 21'}
 }}}

 Django-1.10.7 result (2 queries, total time 0.01):
 {{{
 {'time': '0.003', 'sql': 'SELECT "spatial_ref_sys"."srid",
 "spatial_ref_sys"."auth_name", "spatial_ref_sys"."auth_srid",
 "spatial_ref_sys"."srtext", "spatial_ref_sys"."proj4text" FROM
 "spatial_ref_sys" WHERE "spatial_ref_sys"."srid" = 4326'}
 {'time': '0.007', 'sql': 'SELECT "my_themodel"."id",
 "my_themodel"."polygon_area", "my_themodel"."centroid",
 ST_distance_sphere("my_themodel"."centroid",
 
ST_GeomFromEWKB(\'\\x010120e6101f85eb51b81e374033f34240\'::bytea))
 AS "distance" FROM "my_themodel" WHERE
 ST_distance_sphere("my_themodel"."centroid",
 
ST_GeomFromEWKB(\'\\x010120e6101f85eb51b81e374033f34240\'::bytea))
 <= 3000.0 ORDER BY "my_themodel"."polygon_area" ASC LIMIT 21'}
 }}}

 After upgrading to Django 1.11, Google spends around 600ms to download the
 page which was downloaded in 350ms using Django 1.10.7, as illustrated in
 the image below:

 [[Image(https://yadi.sk/i/wWAup3MU3HRx9N)]]

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

Re: [Django] #20939: Convert QuerySet to Query when filtering

[Django]

#20939: Convert QuerySet to Query when filtering
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Simon Charette ):

 In [changeset:"e62ea0bb9cbb54c1eef848871fe3eab2bad268dc" e62ea0bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="e62ea0bb9cbb54c1eef848871fe3eab2bad268dc"
 Refs #20939 -- Moved subquery ordering clearing optimization to the __in
 lookup.

 Queries could potentially be resolved in cases where ordering matter.
 }}}

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

[Django] #28145: Django documention - MySQL database connector - PyMySQL for python 3 support

[Django]

#28145: Django documention - MySQL database connector -  PyMySQL for python 3
support
-+
   Reporter:  kinganu|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Documentation  |Version:  1.11
   Severity:  Normal |   Keywords:  mysql
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Just wanted to notify to add documentation for MySQL python 3 support
 there is a common package used called PyMySQL to connect with database.
 Ive used successfully with flask applications, trying with django now.

 pip install pymysql

 more info here : http://stackoverflow.com/questions/3455/how-to-
 config-django-using-pymysql-as-driver

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * resolution:  fixed => invalid


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

Re: [Django] #28144: Add allow_overwrite kwarg to FileSystemStorage._save

[Django]

#28144: Add allow_overwrite kwarg to FileSystemStorage._save
-+-
 Reporter:  Jon Prindiville  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  File |  Version:  1.11
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  file storage | Triage Stage:
  overwrite  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Jon Prindiville:

Old description:

> I want to be able to construct a filesystem storage backend that will let
> me overwrite files while still leveraging `FileSystemStorage`.
>
> This set of changes
> (https://github.com/django/django/compare/master...jonprindiville
> :filesystemstorage-allow-overwrite) would enable that without changing
> any of the default behaviour of `FileSystemStorage`. In addition to the
> new kwarg, this adds a test for the existing ''no-overwriting''
> behaviour, and a test for the newly enabled ''overwriting'' behaviour.
>
> I'm not sure about what I should enter here for "Version" (could go in
> anywhere, really) and "Has patch" (I don't have a patch, but I do have a
> PR-able branch, linked above. I am assuming that I should wait for review
> here before actually submitting a PR, though)
>
> === HOW?
>
> Just add an `allow_overwrite` kwarg to `FileSystemStorage._save` that a
> subclasser can optionally take advantage of.
>

> === WHY?
>
> You can't do this in a good way today.
>
> A piece of advice I've seen in several places (see [#refs Refs]) for
> creating an overwriting storage backend is to create a subclass of
> `FileSystemStorage` where the `get_available_name` deletes an existing
> file of the same name. This, in my opinion, is a sneaky use of this
> function, based on the name. I guess it works, but that function is not
> called `get_available_name_and_maybe_delete_some_stuff_also`
>
> A less sneaky (but more race-conditiony) implementation I have seen is to
> have `_save` delete the existing file before calling
> `FileSystemStorage._save`.
>
> One of these is deceptive and one loops forever if you're unlucky.
>
> === [=#refs Refs]:
>
> Various incarnations of this "ovewriting" implementation:
> - django-storages, marked as deprecated (https://github.com/jschneier
> /django-storages/blob/1.5.2/storages/backends/overwrite.py)
> - djangosnippets (https://djangosnippets.org/snippets/976/)
> - someone's gist (https://gist.github.com/fabiomontefuscolo/1584462)
> - django-overwrite-storage (https://github.com/ckot/django-overwrite-
> storage/blob/master/overwrite_storage/storage.py)

New description:

 I want to be able to construct a filesystem storage backend that will let
 me overwrite files while still leveraging `FileSystemStorage`.

 This set of changes
 (https://github.com/django/django/compare/master...jonprindiville:ticket_28144)
 would enable that without changing any of the default behaviour of
 `FileSystemStorage`. In addition to the new kwarg, this adds a test for
 the existing ''no-overwriting'' behaviour, and a test for the newly
 enabled ''overwriting'' behaviour.

 I'm not sure about what I should enter here for "Version" (could go in
 anywhere, really) and "Has patch" (I don't have a patch, but I do have a
 PR-able branch, linked above. I am assuming that I should wait for review
 here before actually submitting a PR, though)

 === HOW?

 Just add an `allow_overwrite` kwarg to `FileSystemStorage._save` that a
 subclasser can optionally take advantage of.


 === WHY?

 You can't do this in a good way today.

 A piece of advice I've seen in several places (see [#refs Refs]) for
 creating an overwriting storage backend is to create a subclass of
 `FileSystemStorage` where the `get_available_name` deletes an existing
 file of the same name. This, in my opinion, is a sneaky use of this
 function, based on the name. I guess it works, but that function is not
 called `get_available_name_and_maybe_delete_some_stuff_also`

 A less sneaky (but more race-conditiony) implementation I have seen is to
 have `_save` delete the existing file before calling
 `FileSystemStorage._save`.

 One of these is deceptive and one loops forever if you're unlucky.

 === [=#refs Refs]:

 Various incarnations of this "ovewriting" implementation:
 - django-storages, marked as deprecated (https://github.com/jschneier
 /django-storages/blob/1.5.2/storages/backends/overwrite.py)
 - djangosnippets (https://djangosnippets.org/snippets/976/)
 - someone's gist 

[Django] #28144: Add allow_overwrite kwarg to FileSystemStorage._save

[Django]

#28144: Add allow_overwrite kwarg to FileSystemStorage._save
-+-
   Reporter:  Jon|  Owner:  nobody
  Prindiville|
   Type:  New| Status:  new
  feature|
  Component:  File   |Version:  1.11
  uploads/storage|   Keywords:  file storage
   Severity:  Normal |  overwrite
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I want to be able to construct a filesystem storage backend that will let
 me overwrite files while still leveraging `FileSystemStorage`.

 This set of changes
 (https://github.com/django/django/compare/master...jonprindiville
 :filesystemstorage-allow-overwrite) would enable that without changing any
 of the default behaviour of `FileSystemStorage`. In addition to the new
 kwarg, this adds a test for the existing ''no-overwriting'' behaviour, and
 a test for the newly enabled ''overwriting'' behaviour.

 I'm not sure about what I should enter here for "Version" (could go in
 anywhere, really) and "Has patch" (I don't have a patch, but I do have a
 PR-able branch, linked above. I am assuming that I should wait for review
 here before actually submitting a PR, though)

 === HOW?

 Just add an `allow_overwrite` kwarg to `FileSystemStorage._save` that a
 subclasser can optionally take advantage of.


 === WHY?

 You can't do this in a good way today.

 A piece of advice I've seen in several places (see [#refs Refs]) for
 creating an overwriting storage backend is to create a subclass of
 `FileSystemStorage` where the `get_available_name` deletes an existing
 file of the same name. This, in my opinion, is a sneaky use of this
 function, based on the name. I guess it works, but that function is not
 called `get_available_name_and_maybe_delete_some_stuff_also`

 A less sneaky (but more race-conditiony) implementation I have seen is to
 have `_save` delete the existing file before calling
 `FileSystemStorage._save`.

 One of these is deceptive and one loops forever if you're unlucky.

 === [=#refs Refs]:

 Various incarnations of this "ovewriting" implementation:
 - django-storages, marked as deprecated (https://github.com/jschneier
 /django-storages/blob/1.5.2/storages/backends/overwrite.py)
 - djangosnippets (https://djangosnippets.org/snippets/976/)
 - someone's gist (https://gist.github.com/fabiomontefuscolo/1584462)
 - django-overwrite-storage (https://github.com/ckot/django-overwrite-
 storage/blob/master/overwrite_storage/storage.py)

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

[Django] #28143: CSRF token fails when Debug is disabled and a custom view is used for handler404

[Django]

#28143: CSRF token fails when Debug is disabled and a custom view is used for
handler404
---+
   Reporter:  antigaprime  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  CSRF |Version:  1.11
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I have set a custom 404 view, which uses the render function and passes
 context variables to the view:

 {{{
 def page_not_found(request, **kwargs):
 lang = request.session['lang']
 content_dict = get_all_db_content(lang, '{0}|{1}'.format('all', 'not-
 found'))
 variables = {
 'content_text': content_dict,
 'page_lang': "not-found-{0}".format(lang),
 'page': 'not-found',
 'page_description': get_field_db_content(lang,
 'page_description_not_found'),
 'page_title': get_field_db_content(lang, 'page_title_not_found'),
 }
 return render(request, '404.html', variables, status=404)
 }}}

 In `urls.py` I have the following:


 {{{
 # Project libs
 import mainsite.views as tn_views

 handler404 = tn_views.page_not_found
 }}}

 When `DEBUG` is set to `False`, custom 404 templates are used, and in
 turn, this makes the csrf token validation for the Django Admin panel to
 be rejected, with a `403` error: `CSRF verification failed. Request
 aborted.`.

 Sometimes, I can go back, refresh the page, and attempt a new login, which
 will work, other times it will not.

 Removing the custom 404 view from `urls.py`, or setting `DEBUG` to `True`
 (obviously), fixes the Django admin failed csrf error.

 Another interesting thing is that during some tests, using
 `CSRF_USE_SESSIONS = True` and `CSRF_COOKIE_AGE = None`  instead of
 cookies would fix the Django admin csrf error, but would break all csrf
 validations from the site's frontend.

 

 Additional (relevant?) info:

 Using Redis as a session cache.

 Additional settings:

 {{{
 ALLOWED_HOSTS = [
 '.mysite.com',
 '.mysite.info',
 ]

 if DEBUG:
 ALLOWED_HOSTS.extend(['.mysite.dev'])

 MIDDLEWARE = [
 'django.middleware.cache.UpdateCacheMiddleware',
 'django.middleware.security.SecurityMiddleware',
 'django.middleware.gzip.GZipMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.locale.LocaleMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'django.middleware.cache.FetchFromCacheMiddleware',
 'mainsite.middleware.Guid',
 'mainsite.middleware.SiteLang',
 ]

 TEMPLATES = [
 {
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': [
 os.path.join(BASE_DIR, '_templates'),
 ],
 'APP_DIRS': True,
 'OPTIONS': {
 'context_processors': [
 'django.template.context_processors.debug',
 'django.template.context_processors.request',
 'django.contrib.auth.context_processors.auth',
 'django.contrib.messages.context_processors.messages',
 'mainsite.context.site_variables',
 'mainsite.context.sitelang',
 ],
 },
 },
 ]
 }}}

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mateuspadua):

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mateuspadua):

 Thanks for replay:

 I did more tests and i figure out that my constraint was without the
 options Deferrable and Deferred assigned, because my current DB PostgreSQL
 was migrate from MySQL. Then I assigned this options manually on DB and
 worked.

 
[[Image(https://drive.google.com/file/d/0B7FKYDMJBG3bVVBCM1k3X0tsUEk/view?usp=sharing)]]

 More information about this options on the link bellow:
 http://stackoverflow.com/questions/16323236/deferrable-check-constraint-
 in-postgresql

 I hope this can help.

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

Re: [Django] #28040: Update SplitArrayWidget to use template-based widget rendering

[Django]

#28040: Update SplitArrayWidget to use template-based widget rendering
-+-
 Reporter:  Dariusz Paluch   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  1.11
 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 Claude Paroz):

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

Re: [Django] #28129: Allow custom template tags to accept keyword only arguments

[Django]

#28129: Allow custom template tags to accept keyword only arguments
-+-
 Reporter:  Alexander|Owner:  nobody
  Allakhverdiyev |
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  template,inspect | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alexander Allakhverdiyev):

 Okay, thank you! I've submitted
 [https://github.com/django/django/pull/8428 PR#8428] to use
 {{{inspect.getfullargspec()}}} and rebased the patch.

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

Re: [Django] #28130: Formset validate_min validation ignores unchanged forms

[Django]

#28130: Formset validate_min validation ignores unchanged forms
-+-
 Reporter:  Jim Ouwerkerk|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  formsets | 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 Claude Paroz):

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

Re: [Django] #28062: Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor errors

[Django]

#28062: Using QuerySet.iterator() with pgBouncer leads to nonexistent cursor 
errors
-+-
 Reporter:  Sergey Fursov|Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 François Freitag):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8430 PR]

 Working on this issue, I came to the conclusions that {{{None}}} is not
 necessary and I prefer the simpler scheme where:

 * the use of server-side cursors is disabled for a connection if the
 setting is {{{False}}}.
 * when the setting is {{{True}}}, server-side cursors are used by default
 and users and library code can opt-out specifying
 {{{chunked_fetch=False}}}.

 I believe auto opt-in server-side cursors is acceptable, since it's a
 memory improvement in most case. The issue here is that server-side
 cursors cannot be used with transaction pooling, which is global to a
 connection. Setting {{{ENABLE_SERVER_SIDE_CURSORS}}} to {{{False}}} for
 the whole connection makes sense and should disable the use of server-side
 cursors regardless of the {{{chunked_fetch}}} keyword argument.

 For use cases where server-side cursors are not desirable, the user /
 library-code can now turn them off explicitly using
 {{{chunked_fetch=False}}}.

 I think this solution is simpler and covers the use cases I can think of.
 Am I missing something?

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

Re: [Django] #28140: Add convenience method to add `Permission`s to a `User`

[Django]

#28140: Add convenience method to add  `Permission`s to a `User`
+-
 Reporter:  Flavio Curella  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Someday/Maybe
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-

Comment (by Flavio Curella):

 Thank Tim,

 I will work on a proposal for #25281. Once that's resolve, I can move on
 to this one.

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

Re: [Django] #28140: Add convenience method to add `Permission`s to a `User` (was: Add convenience manager method to `Permission`s)

[Django]

#28140: Add convenience method to add  `Permission`s to a `User`
+-
 Reporter:  Flavio Curella  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Someday/Maybe
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  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.11131826134c1fc4f3b10f9e8684e991%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28140: Add convenience manager method to `Permission`s

[Django]

#28140: Add convenience manager method to `Permission`s
+-
 Reporter:  Flavio Curella  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Someday/Maybe
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 There's the problem described in #25281 that `"."` might not uniquely identify permissions. Anyway, a proposal
 like this should be made on the DevelopersMailingList to see if there's
 consensus, however, the existence of
 
[https://github.com/django/django/blob/8095496a1c07a68d0904d594cdc3b1d9557625e0/tests/admin_views/tests.py#L1325-L1328
 a helper in Django's test suite] to help ease the verbosity here is a good
 indication that something could be done. I'm bit confused because the
 ticket's summary talks about adding a manager method to Permission but the
 description proposes adding a user method. In the latter case, a
 consideration of custom user models might be needed.

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Could you please provide code to reproduce the issue (a sample project,
 for example) that doesn't involve a third-party project (django-cms in
 this case) so we can rule out a bug in that package?

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

Re: [Django] #28142: is_safe_url() raises ValueError for invalid IPv6 URLs (was: Login ends up with ValueError with some next URLs)

[Django]

#28142: is_safe_url() raises ValueError for invalid IPv6 URLs
--+
 Reporter:  Michal Čihař  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Utilities |  Version:  1.11
 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 Tim Graham):

 * stage:  Unreviewed => Accepted
 * component:  contrib.auth => Utilities
 * easy:  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/063.b5ab69e6ec6cb5a8733c1116a923213a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26844: Formset's validate_min doesn't work correctly with empty forms

[Django]

#26844: Formset's validate_min doesn't work correctly with empty forms
+-
 Reporter:  Wim Feijen  |Owner:  Manasa Patibandla
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.9
 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 Tim Graham):

 The new ticket is #28130.

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

Re: [Django] #28130: Formset validate_min validation ignores unchanged forms

[Django]

#28130: Formset validate_min validation ignores unchanged forms
-+
 Reporter:  Jim Ouwerkerk|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:  formsets | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8426 PR]

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by mateuspadua:

Old description:

> Example:
>

> {{{
> from cms.models import Page
>

> class OfferingPlugin(models.Model):
> image = VersatileImageField(upload_to=unique_upload,
> ppoi_field='ppoi')
> ppoi = PPOIField()
> title = models.CharField(max_length=50)
> subtitle = models.CharField(max_length=140)
> link_copy = models.CharField(max_length=20)
> link_address = models.ForeignKey(Page, blank=True, null=True,
> on_delete=models.CASCADE) ** -> dont work because has null=True**
>
> 
>
> page = Page.objecs.first()
>
> }}}
>
> If I to try delete a Page instance, for example page.delete() the error
> bellow will occur:
>
> .
>
> IntegrityError: insert or update on table "offering_offeringplugin"
> violates foreign key constraint
> "offering_offering_cmsplugin_ptr_id_9a9e9998_fk_cms_cmsplugin_id"
> DETAIL:  Key (id)=(10) is still referenced from table
> "offering_offeringplugin".

New description:

 Example:


 {{{
 from cms.models import Page


 class OfferingPlugin(models.Model):
 title = models.CharField(max_length=50)
 subtitle = models.CharField(max_length=140)
 link_copy = models.CharField(max_length=20)
 link_address = models.ForeignKey(Page, blank=True, null=True,
 on_delete=models.CASCADE) ** -> dont work because has null=True**

 

 page = Page.objecs.first()

 }}}

 If I to try delete a Page instance, for example page.delete() the error
 bellow will occur:

 .

 IntegrityError: insert or update on table "offering_offeringplugin"
 violates foreign key constraint
 "offering_offering_cmsplugin_ptr_id_9a9e9998_fk_cms_cmsplugin_id"
 DETAIL:  Key (id)=(10) is still referenced from table
 "offering_offeringplugin".

--

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by mateuspadua:

Old description:

> Example:
>

> {{{
> from cms.models import Page
>

> class OfferingPlugin(CMSPlugin):
> image = VersatileImageField(upload_to=unique_upload,
> ppoi_field='ppoi')
> ppoi = PPOIField()
> title = models.CharField(max_length=50)
> subtitle = models.CharField(max_length=140)
> link_copy = models.CharField(max_length=20)
> link_address = models.ForeignKey(Page, blank=True, null=True,
> on_delete=models.CASCADE) ** -> dont work because has null=True**
>
> 
>
> page = Page.objecs.first()
>
> }}}
>
> If I to try delete a Page instance, for example page.delete() the error
> bellow will occur:
>
> .
>
> IntegrityError: insert or update on table "offering_offeringplugin"
> violates foreign key constraint
> "offering_offering_cmsplugin_ptr_id_9a9e9998_fk_cms_cmsplugin_id"
> DETAIL:  Key (id)=(10) is still referenced from table
> "offering_offeringplugin".

New description:

 Example:


 {{{
 from cms.models import Page


 class OfferingPlugin(models.Model):
 image = VersatileImageField(upload_to=unique_upload,
 ppoi_field='ppoi')
 ppoi = PPOIField()
 title = models.CharField(max_length=50)
 subtitle = models.CharField(max_length=140)
 link_copy = models.CharField(max_length=20)
 link_address = models.ForeignKey(Page, blank=True, null=True,
 on_delete=models.CASCADE) ** -> dont work because has null=True**

 

 page = Page.objecs.first()

 }}}

 If I to try delete a Page instance, for example page.delete() the error
 bellow will occur:

 .

 IntegrityError: insert or update on table "offering_offeringplugin"
 violates foreign key constraint
 "offering_offering_cmsplugin_ptr_id_9a9e9998_fk_cms_cmsplugin_id"
 DETAIL:  Key (id)=(10) is still referenced from table
 "offering_offeringplugin".

--

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

[Django] #28142: Login ends up with ValueError with some next URLs

[Django]

#28142: Login ends up with ValueError with some next URLs
+
   Reporter:  Michal Čihař  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.auth  |Version:  1.11
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The is_safe_url function can raise ValueError from _urlsplit. IMHO it
 should catch the error from parsing and return False in this case.

 This can happen for example with `next=http://168.192.0.1]`

 Traceback from 1.10, but it happens on 1.11 as well (and actually raises
 the ValueError even on the login page as it is now doing the validation).

 {{{
 File "/usr/lib/python2.7/dist-packages/django/contrib/auth/views.py" in
 inner
   47. return func(*args, **kwargs)

 File "/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py"
 in sensitive_post_parameters_wrapper
   76. return view(request, *args, **kwargs)

 File "/usr/lib/python2.7/dist-packages/django/utils/decorators.py" in
 _wrapped_view
   149. response = view_func(request, *args, **kwargs)

 File "/usr/lib/python2.7/dist-packages/django/views/decorators/cache.py"
 in _wrapped_view_func
   57. response = view_func(request, *args, **kwargs)

 File "/usr/lib/python2.7/dist-packages/django/contrib/auth/views.py" in
 login
   83. return
 HttpResponseRedirect(_get_login_redirect_url(request, redirect_to))

 File "/usr/lib/python2.7/dist-packages/django/contrib/auth/views.py" in
 _get_login_redirect_url
   53. if not is_safe_url(url=redirect_to, host=request.get_host()):

 File "/usr/lib/python2.7/dist-packages/django/utils/http.py" in
 is_safe_url
   309. return _is_safe_url(url, host) and
 _is_safe_url(url.replace('\\', '/'), host)

 File "/usr/lib/python2.7/dist-packages/django/utils/http.py" in
 _is_safe_url
   369. url_info = _urlparse(url)

 File "/usr/lib/python2.7/dist-packages/django/utils/http.py" in _urlparse
   321. splitresult = _urlsplit(url, scheme, allow_fragments)

 File "/usr/lib/python2.7/dist-packages/django/utils/http.py" in _urlsplit
   355. raise ValueError("Invalid IPv6 URL")

 Exception Type: ValueError at /accounts/login/
 Exception Value: Invalid IPv6 URL
 }}}

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

Re: [Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey null  | Triage Stage:
  True PostgreSQL|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by mateuspadua:

Old description:

> Example:
>
> from cms.models import Page
>

> class OfferingPlugin(CMSPlugin):
> image = VersatileImageField(upload_to=unique_upload,
> ppoi_field='ppoi')
> ppoi = PPOIField()
> title = models.CharField(max_length=50)
> subtitle = models.CharField(max_length=140)
> link_copy = models.CharField(max_length=20)
> link_address = models.ForeignKey(Page, blank=True, null=True,
> on_delete=models.CASCADE) ** -> dont work because has null=True**
>
> 
>
> page = Page.objecs.first()
>
> If I to try delete a Page instance, for example page.delete() the error
> bellow will occur:
>
> .
>
> IntegrityError: insert or update on table "offering_offeringplugin"
> violates foreign key constraint
> "offering_offering_cmsplugin_ptr_id_9a9e9998_fk_cms_cmsplugin_id"
> DETAIL:  Key (id)=(10) is still referenced from table
> "offering_offeringplugin".

New description:

 Example:


 {{{
 from cms.models import Page


 class OfferingPlugin(CMSPlugin):
 image = VersatileImageField(upload_to=unique_upload,
 ppoi_field='ppoi')
 ppoi = PPOIField()
 title = models.CharField(max_length=50)
 subtitle = models.CharField(max_length=140)
 link_copy = models.CharField(max_length=20)
 link_address = models.ForeignKey(Page, blank=True, null=True,
 on_delete=models.CASCADE) ** -> dont work because has null=True**

 

 page = Page.objecs.first()

 }}}

 If I to try delete a Page instance, for example page.delete() the error
 bellow will occur:

 .

 IntegrityError: insert or update on table "offering_offeringplugin"
 violates foreign key constraint
 "offering_offering_cmsplugin_ptr_id_9a9e9998_fk_cms_cmsplugin_id"
 DETAIL:  Key (id)=(10) is still referenced from table
 "offering_offeringplugin".

--

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

[Django] #28141: When have null=True inside ForeignKey, Django don't to do CASCADE Operation even passing on_delete=models.CASCADE. [using PostgreSQL]

[Django]

#28141: When have null=True inside ForeignKey, Django don't to do CASCADE 
Operation
even passing on_delete=models.CASCADE. [using PostgreSQL]
-+-
   Reporter: |  Owner:  nobody
  mateuspadua|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.10
  layer (models, ORM)|   Keywords:  ForeignKey null
   Severity:  Normal |  True PostgreSQL
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Example:

 from cms.models import Page


 class OfferingPlugin(CMSPlugin):
 image = VersatileImageField(upload_to=unique_upload,
 ppoi_field='ppoi')
 ppoi = PPOIField()
 title = models.CharField(max_length=50)
 subtitle = models.CharField(max_length=140)
 link_copy = models.CharField(max_length=20)
 link_address = models.ForeignKey(Page, blank=True, null=True,
 on_delete=models.CASCADE) ** -> dont work because has null=True**

 

 page = Page.objecs.first()

 If I to try delete a Page instance, for example page.delete() the error
 bellow will occur:

 .

 IntegrityError: insert or update on table "offering_offeringplugin"
 violates foreign key constraint
 "offering_offering_cmsplugin_ptr_id_9a9e9998_fk_cms_cmsplugin_id"
 DETAIL:  Key (id)=(10) is still referenced from table
 "offering_offeringplugin".

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

[Django] #28140: Add convenience manager method to `Permission`s

[Django]

#28140: Add convenience manager method to `Permission`s
--+
   Reporter:  Flavio Curella  |  Owner:  nobody
   Type:  New feature | Status:  new
  Component:  contrib.auth|Version:  1.11
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When writing tests checking for permissions, it's commonplace to test if a
 user can access a particular view, check for failure, add the necessary
 permission, then check again for success:

 {{{
 def mytest(self):
 user = User.objects.create_user(
 username='regularuser',
 password='regularuser',
 )
 response = self.client.get('/mymodel/create/')
 # Usually redirects to some other page, such as `/login/`
 self.assertNotEqual(response.status_code, 200)

 # then we fetch the 'myapp.add_mymodel' permission and add it to
 `user`
 my_permission = Permission.objects.get_by_natural_key('add_mymodel',
 'myapp', 'mymodel')
 user.user_permissions.add(mypermission)

 response = self.client.get('/mymodel/create/')
 # now it works
 self.assertEqual(response.status_code, 200)

 }}}

 I'm wondering if we should have a more convenient way to add permissions.
 I'm thinking of adding a `add_perm` method to the `User` model, that
 mirrors the already existing
 
[https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.auth.models.User.has_perm
 `has_perm`] so that instead of

 {{{
 my_permission = Permission.objects.get_by_natural_key('add_mymodel',
 'myapp', 'mymodel')
 user.user_permissions.add(mypermission)

 response = self.client.get('/mymodel/create/')
 self.assertEqual(response.status_code, 200)
 }}}

 we can have:

 {{{
 user.add_perm('myapp.add_mymodel')
 response = self.client.get('/mymodel/create/')
 self.assertEqual(response.status_code, 200)
 }}}

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

Re: [Django] #27753: Cleanups when no supported version of Django supports Python 2 anymore

[Django]

#27753: Cleanups when no supported version of Django supports Python 2 anymore
-+-
 Reporter:  Aymeric Augustin |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Tim Graham:

Old description:

> Compatibility with Python 2 is currently being removed in master as part
> of the Django 2.0 development cycle: see #23919.
>
> However third-party apps may want to remain compatible with all supported
> version of Django and the corresponding versions of Python, which
> includes Python 2.
>
> To allow this, compatibility functions or modules aren't removed. They're
> still importable. They're usually just aliases or no-ops. Here's a list
> of things to deprecate and remove eventually:
>
> - django.utils.six
> - django.utils.lru_cache
> - django.utils._os.abspathu, upath, npath
> - django.utils.decorators.available_attrs
> - django.utils.encoding.python_2_unicode_compatible
> - django.utils.encoding.smart/force_text
> - django.utils.http.urlquote/urlquote_plus/urlunquote/urlunquote_plus
> ([https://github.com/django/django/pull/7906/commits/5861ce799ddb3f5912f9e16503d4239fa9d80e66
> unmerged commit])
> - django.utils.safestring.SafeBytes
> - One of either
> [https://github.com/django/django/blob/9718fa2e8abe430c3526a9278dd976443d4ae3c6/django/utils/safestring.py#L61
> django.utils.safestring.SafeString] or django.utils.safestring.SafeText

New description:

 Compatibility with Python 2 is currently being removed in master as part
 of the Django 2.0 development cycle: see #23919.

 However third-party apps may want to remain compatible with all supported
 version of Django and the corresponding versions of Python, which includes
 Python 2.

 To allow this, compatibility functions or modules aren't removed. They're
 still importable. They're usually just aliases or no-ops. Here's a list of
 things to deprecate and remove eventually:

 - django.utils.six
 - django.utils.lru_cache
 - django.utils._os.abspathu, upath, npath
 - django.utils.decorators.available_attrs
 - django.utils.encoding.python_2_unicode_compatible
 - django.utils.encoding.smart/force_text
 - django.utils.http.urlquote/urlquote_plus/urlunquote/urlunquote_plus
 
([https://github.com/django/django/pull/7906/commits/5861ce799ddb3f5912f9e16503d4239fa9d80e66
 unmerged commit])
 - django.utils.safestring.SafeBytes
 - One of either
 
[https://github.com/django/django/blob/9718fa2e8abe430c3526a9278dd976443d4ae3c6/django/utils/safestring.py#L61
 django.utils.safestring.SafeString] or django.utils.safestring.SafeText
 - django.test.utils.str_prefix()

--

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

Re: [Django] #28129: Allow custom template tags to accept keyword only arguments

[Django]

#28129: Allow custom template tags to accept keyword only arguments
-+-
 Reporter:  Alexander|Owner:  nobody
  Allakhverdiyev |
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  template,inspect | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Okay, [http://bugs.python.org/issue27172#msg292408 Nick confirmed] that
 `getfullargspec()` won't be deprecated in the future. Could you submit a
 separate PR to replace `django.utils.inspect.getargspec()` with it? You
 can rebase the patch for this ticket after that's completed.

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

[Django] #28139: Add one more level in the topics main index

[Django]

#28139: Add one more level in the topics main index
-+
   Reporter:  Shai Berger|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Documentation  |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+
 I was just looking for the middleware documentation, and when looking at
 https://docs.djangoproject.com/en/1.11/topics/ I didn't see it listed
 there. I kept searching, and eventually found it at
 https://docs.djangoproject.com/en/1.11/topics/http/middleware/ -- in the
 main index, it was "hidden" in
 https://docs.djangoproject.com/en/1.11/topics/http/ together with many
 other issues.

 The title "handling HTTP requests" is not descriptive enough to hint at
 all the goodness you'll find underneath it, and I'm betting there are
 other topics like it; I think it would be better if we included at least
 one more level of this branching in the main topics index.

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

Re: [Django] #28138: Use cursor output type handler on Oracle.

[Django]

#28138: Use cursor output type handler on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle cx_Oracle | 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):

 * stage:  Unreviewed => 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/065.b36ec126d89a073dad104807ff59b5c2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

[Django]

#23919: Cleanups for when we drop Python 2 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:
 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 Claude Paroz ):

 In [changeset:"59f8118c86af7641f23a9f2c2e0812c8b1ba47dd" 59f8118c]:
 {{{
 #!CommitTicketReference repository=""
 revision="59f8118c86af7641f23a9f2c2e0812c8b1ba47dd"
 Refs #23919 -- Removed force_text() in Python deserializer needed only on
 Python 2
 }}}

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

Re: [Django] #27795: Audit force_text invocations

[Django]

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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 Claude Paroz ):

 In [changeset:"a8343fe7bf0ec237d8f77ba4e729ae093388b75f" a8343fe7]:
 {{{
 #!CommitTicketReference repository=""
 revision="a8343fe7bf0ec237d8f77ba4e729ae093388b75f"
 Refs #27795 -- Replaced force_text() with str() in feed generators
 }}}

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

Re: [Django] #27795: Audit force_text invocations

[Django]

#27795: Audit force_text invocations
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 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 Claude Paroz ):

 In [changeset:"301de774c21d055e9e5a7073e5bffdb52bc71079" 301de77]:
 {{{
 #!CommitTicketReference repository=""
 revision="301de774c21d055e9e5a7073e5bffdb52bc71079"
 Refs #27795 -- Replaced many force_text() with str()

 Thanks Tim Graham for the 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.8038edf35820f9e54a8ce3a1b9e8d3ee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28138: Use cursor output type handler on Oracle.

[Django]

#28138: Use cursor output type handler on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle cx_Oracle | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8420 PR]

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