Re: [Django] #31864: Session data cannot be decoded during the transition to Django 3.1.

[Django]

#31864: Session data cannot be decoded during the transition to Django 3.1.
--+
 Reporter:  felixxm   |Owner:  felixxm
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  3.1
 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 Carlton Gibson):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #31864: Session data cannot be decoded during the transition to Django 3.1.

[Django]

#31864: Session data cannot be decoded during the transition to Django 3.1.
--+--
 Reporter:  felixxm   |Owner:  felixxm
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  3.1
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

 * cc: Markus Holtermann, Florian Apolloner, Carlton Gibson, אורי (added)
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13279 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ade90c9c7d3d49662f7e42ea98d376d7%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+
 Reporter:  Markus Holtermann  |Owner:  felixxm
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  3.1
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by felixxm):

 אורי this is a separate issue, sessions respect
 `DEFAULT_HASHING_ALGORITHM`, but format has changed, see #31864.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b0599cc5f6c08464c14c86eb571548e9%40djangoproject.com.

[Django] #31864: Session data cannot be decoded during the transition to Django 3.1.

[Django]

#31864: Session data cannot be decoded during the transition to Django 3.1.
+--
   Reporter:  felixxm   |  Owner:  felixxm
   Type:  Bug   | Status:  assigned
  Component:  contrib.sessions  |Version:  3.1
   Severity:  Release blocker   |   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
 In d4fff711d4c97356bd6ba1273d2a5e349326eb5f (#31274) we've changed format
 for session data, that's why setting `DEFAULT_HASHING_ALGORITHM` to
 `'sha1'` is not enough to support running multiple instances of the same
 project during the transition to Django 3.1.

 We could use the legacy `encode()` when `DEFAULT_HASHING_ALGORITHM ==
 'sha1'` (it's a bit hacky).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.bb0609f0df8251c817dcd019133471de%40djangoproject.com.

Re: [Django] #31863: FK field caching behavior change between 1.11.x and 2.x

[Django]

#31863: FK field caching behavior change between 1.11.x and 2.x
-+-
 Reporter:  Gert Burger  |Owner:  Gert
 |  Burger
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
-+
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  feature test models  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Filipe Pina):

 Thank you Simon for that clean life saving piece of code!
 Been using for a few months and just today had to use a test child model
 of a real model so bumped into the lack of migrations.
 Just defined it in the main models, ran makemigrations and moved that new
 migration into “tests/migrations”, worked perfectly.

 Hope this makes it into a release “soon” :)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.195520b1d9ed8dfaae48d2feaceee898%40djangoproject.com.

Re: [Django] #31852: Support async generators in StreamingHttpResponse

[Django]

#31852: Support async generators in StreamingHttpResponse
---+--
 Reporter:  Axel Hecht |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  3.1
 Severity:  Normal |   Resolution:  needsinfo
 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 Andrew Godwin):

 We definitely should expand to add this, but async generators are quite
 tough to support across a range of Python versions; they get increasingly
 better to use every version. I think the best approach here would be an
 exploratory patch to see what we can get that looks reasonable given
 Django's current supported Python versions - 3.6 might be a high enough
 baseline (3.5 is very problematic), but it might be a thing that's easier
 in a future 3.7+ 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.0218f2c5535999526e29735ad19d206b%40djangoproject.com.

[Django] #31863: FK field caching behavior change between 1.11.x and 2.x

[Django]

#31863: FK field caching behavior change between 1.11.x and 2.x
-+-
   Reporter:  Gert   |  Owner:  Gert Burger
  Burger |
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  3.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Whilst upgrading a codebase from 1.11.x to 2.0/2.2 I noticed a weird
 change in behavior of FK fields when copying model instances.

 At the bottom of the post there is a testcase that succeeds on 1.11.x and
 fails on 2.x
 I think the commit that changed the behavior is
 bfb746f983aa741afa3709794e70f1e0ab6040b5

 So my question is two fold:
 * Is the behavior in >=2.0 correct? It seems quite unexpected.
 * What is the recommended way to clone a model instance? To date we have
 been using copy() in a similar fashion to the test without issue. deepcopy
 seems to work fine in >=2.0 but we haven’t done too much testing yet.

 Test (placed in tests/model_fields/test_field_caching_change.py):

 {{{#!python

 import copy
 from django.test import TestCase

 from .models import Bar, Foo


 class ForeignKeyCachingBehaviorTest(TestCase):
 def test_copy(self):
 foo1 = Foo.objects.create(a='foo1', d=1)
 foo2 = Foo.objects.create(a='foo2', d=2)
 bar1 = Bar.objects.create(a=foo1, b='bar1')

 bar2 = copy.copy(bar1)

 bar2.pk = None
 bar2.a = foo2

 # bar2 points to foo2
 self.assertEqual(bar2.a, foo2)
 self.assertEqual(bar2.a.id, bar2.a_id)

 # bar1 is unchanged and must still point to foo1
 # These fail on Django >= 2.0
 self.assertEqual(bar1.a, foo1)
 self.assertEqual(bar1.a.id, bar1.a_id)

 }}}

 and executed that via:

 python3.6 tests/runtests.py --parallel 1 model_fields



 In https://groups.google.com/g/django-
 developers/c/QMhVPIqVVP4/m/mbezfaBEAwAJ Simon suggests:
 > . Model.__copy__ should make sure to make a deep-copy of self._state
 now that fields are cached in self._state.fields_cache.

 which I will attempt to implement.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.5dc81ec4add29cc41b01ba8f8fcacc74%40djangoproject.com.

Re: [Django] #24342: Add EnumField model/form fields

[Django]

#24342: Add EnumField model/form fields
-+-
 Reporter:  Thomas Stephenson|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 George Sakkis):

 * cc: George Sakkis (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.5529b2641c04a6ce1cf75562c8ad90ef%40djangoproject.com.

Re: [Django] #30950: Replace __file__ with importlib.resources

[Django]

#30950: Replace __file__ with importlib.resources
-+-
 Reporter:  John Vandenberg  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  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
-+-
Changes (by William Schwartz):

 * cc: William Schwartz (added)


Comment:

 Support for PyOxidizer is important to my use case.

 In addition to the issue of package data, for which `importlib.resources`
 is a good solution, there's also the matter of management commands. The
 current algorithm uses the standard library's `pkgutil.iter_modules`,
 which only works with file-system based code. A good alternative that
 would work for non-file code would be to use the import mechanism as
 follows. The following code would replace
 
[https://github.com/django/django/blob/0a306f7da668e53af2516bfad759b52d6c650b69/django/core/management/__init__.py#L41-L73
 django.core.management.get_commands()] and
 
[https://github.com/django/django/blob/0a306f7da668e53af2516bfad759b52d6c650b69/django/core/management/__init__.py#L21-L28
 django.core.management.find_commands()]. I made some effort to keep the
 code similar to the existing code. I dressed up some of the docstring for
 Sphinx in case a description of the algorithm would need to go into the
 docs.

 {{{
 #!python
 import functools
 from importlib import import_module
 from types import ModuleType
 from typing import Dict, List

 from django.apps import apps
 from django.conf import settings
 from django.core.management.base import BaseCommand


 def find_commands(management_pkg_name: str) -> List[str]:
 """Given the name of a management package, return a list of all the
 command
 names that are available.
 """
 commands_pkg_name = '.'.join([management_pkg_name, 'commands'])
 try:
 pkg = import_module(commands_pkg_name)
 except ModuleNotFoundError:
 continue
 return [name for name, obj in pkg.__dict__.items()
 if isinstance(obj, ModuleType)
 # Django's rules ignore modules whose names start with _ or is a
 package
 # A module has a __path__ attribute if and only if it's a package
 and not hasattr(obj, '__path__')
 and not obj.__name__.startswith('_')
 # Ignore incidental imports from other packages into __init__.py
 and obj.__package__ == commands_pkg_name
 # We only care if there's a BaseCommand subclass named Command
 and hasattr(obj, 'Command')
 and issubclass(obj.Command, BaseCommand)
 ]


 @functools.lru_cache(maxsize=None)
 def get_commands_by_import() -> Dict[str, str]:
 r"""Find :doc:`django:ref/django-admin` commands via the import
 system.

 Look for a management.commands package in django.core, and in each
 installed application — if a commands package exists, register all
 commands in that package.

 Core commands are always included. If a settings module has been
 specified, also include user-defined commands.

 The dictionary is in the format {command_name: app_name}. Key-value
 pairs from this dictionary can then be used in calls to
 load_command_class(app_name, command_name)

 If a specific version of a command must be loaded (e.g., with the
 startapp command), the instantiated module can be placed in the
 dictionary in place of the application name.

 The dictionary is cached on the first call and reused on subsequent
 calls.

 :returns:
 A dictionary mapping :samp:`{command}` names to the :samp:`{app}`
 they
 come from. For each :samp:`{app}` in :setting:`INSTALLED_APPS`, we
 search for an :samp:`{app}.management.commands.{command}` module
 by
 trying to import :samp:`{app}.management.commands`, iterating
 through
 the module's :attr:`~object.__dict__`,  and testing its values. We
 include any :class:`types.ModuleType` :samp:`{command}` if its
 name does
 not start with an underscore (``_``), it's not a
 :term:`python:package`,
 and it has a :class:`django.core.management.BaseCommand` subclass
 called
 ``Command``.
 """
 commands = {name: 'django.core' for name in
 find_commands(__package__)}

 if not settings.configured:
 return commands

 for app_config in reversed(list(apps.get_app_configs())):
 pkg_name = '.'.join([app_config.name, 'management'])
 commands.update({name: app_config.name for name in
 find_commands(pkg_name)})

Re: [Django] #30422: Temporary files do not get deleted on canceled upload request.

[Django]

#30422: Temporary files do not get deleted on canceled upload request.
-+-
 Reporter:  drutalj  |Owner:  Sanskar
 |  Jaiswal
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  master
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sanskar Jaiswal):

 All tests run on my machine (macOS) but the CI test on Windows fails
 because of a PermissionError, due to the temporary file being used by some
 other process. Is there any possible fix for this on Windows? Or should I
 just alter my patch to handle such os errors and label this patch as POSIX
 only?

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

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

Re: [Django] #21181: collation specific query results ordering

[Django]

#21181: collation specific query results ordering
-+-
 Reporter:  alan.kesselmann@…|Owner:  Alan
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * cc: Simon Charette (added)


Comment:

 Looks like collation names are identifiers on these backends and need to
 be escaped using `connection.ops.quote_name`. Was MySQL also behaving this
 way?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/083.24bc6cf7a2947d0c24605bd5da29745b%40djangoproject.com.

Re: [Django] #31862: Add ArrayField for all supported databases - not only postgres

[Django]

#31862: Add ArrayField for all supported databases - not only postgres
-+-
 Reporter:  אורי |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 To you point though, it was pointed out in the discussion leading to the
 recent changes that ArrayField would be simple enough for a user to
 simulate in their own project.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.676fe9274e8a31ba922c80892c49a7a2%40djangoproject.com.

Re: [Django] #31862: Add ArrayField for all supported databases - not only postgres

[Django]

#31862: Add ArrayField for all supported databases - not only postgres
-+-
 Reporter:  אורי |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 ArrayField maps to [https://www.postgresql.org/docs/9.1/arrays.html
 Postgres arrays] which aren't supported on other DBs.

 Please don't use the issue tracker for general questions. A quick search
 of the DevelopersMailingList or the related tickets here would show the
 history of this topic quite easily.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.191dfe4c349e1647fca316f1cafc8ce3%40djangoproject.com.

[Django] #31862: Add ArrayField for all supported databases - not only postgres

[Django]

#31862: Add ArrayField for all supported databases - not only postgres
-+-
   Reporter:  אורי   |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `JSONField` has been moved from `django.contrib.postgres.fields` to
 `django.db.models` in Django 3.1. Can you move `ArrayField` too from
 `django.contrib.postgres.fields` to `django.db.models`? Is there a
 technical reason why `ArrayField` cannot be supported by all databases?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.1086c8e06260cfb6e820ee7bbaee4783%40djangoproject.com.

Re: [Django] #25513: Refactor the admin paginator customizations to make them reuseable

[Django]

#25513: Refactor the admin paginator customizations to make them reuseable
-+-
 Reporter:  Vlada Macek  |Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  paginator, ellipsis  | 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 Carlton Gibson ):

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


Comment:

 In [changeset:"0a306f7da668e53af2516bfad759b52d6c650b69" 0a306f7]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a306f7da668e53af2516bfad759b52d6c650b69"
 Fixed #25513 -- Extracted admin pagination to
 Paginator.get_elided_page_range().
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ce9522ba9b66dbc2c807d8b5f8f6f500%40djangoproject.com.

Re: [Django] #25513: Refactor the admin paginator customizations to make them reuseable

[Django]

#25513: Refactor the admin paginator customizations to make them reuseable
-+-
 Reporter:  Vlada Macek  |Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  paginator, ellipsis  | 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 Carlton Gibson ):

 In [changeset:"f35840c19664fed7b6bc4cf561bf0b6fd1a3b463" f35840c1]:
 {{{
 #!CommitTicketReference repository=""
 revision="f35840c19664fed7b6bc4cf561bf0b6fd1a3b463"
 Refs #25513 -- Fixed admin pagination elision bounds.

 It doesn't make sense to elide a single page number which could be a
 clickable link to that page. We only want to elide two or more pages.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.bf9e8d3fed361d7b6c273613dcd56114%40djangoproject.com.

Re: [Django] #25513: Refactor the admin paginator customizations to make them reuseable

[Django]

#25513: Refactor the admin paginator customizations to make them reuseable
-+-
 Reporter:  Vlada Macek  |Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  paginator, ellipsis  | 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 Carlton Gibson ):

 In [changeset:"b203ec70fd7ffc4027380940157d1cf9c9e588ad" b203ec70]:
 {{{
 #!CommitTicketReference repository=""
 revision="b203ec70fd7ffc4027380940157d1cf9c9e588ad"
 Refs #25513 -- Adjusted admin pagination to be 1-indexed.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e63491e4e33a0e6f4ad06a74407b331c%40djangoproject.com.

Re: [Django] #25513: Refactor the admin paginator customizations to make them reuseable

[Django]

#25513: Refactor the admin paginator customizations to make them reuseable
-+-
 Reporter:  Vlada Macek  |Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  paginator, ellipsis  | 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 Carlton Gibson):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.2bd13e32c626e1c96609432e398dc612%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+
 Reporter:  Markus Holtermann  |Owner:  felixxm
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  3.1
 Severity:  Release blocker|   Resolution:  fixed
 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 אורי):

 * cc: אורי (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.73ddb8fcce99379e0a396995a3d03978%40djangoproject.com.

Re: [Django] #31842: django.core.signing.dumps() and loads() not backwards compatible

[Django]

#31842: django.core.signing.dumps() and loads() not backwards compatible
---+
 Reporter:  Markus Holtermann  |Owner:  felixxm
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  3.1
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by אורי):

 Does `DEFAULT_HASHING_ALGORITHM = 'sha1'` work for you with several
 servers with Django 3.1 and 3.0? I checked on my staging server and it
 seems not to work - exceptions are raised if I revert from Django 3.1 to
 3.0 after users log in.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.90da791ea2d5cea18a143abeed21b622%40djangoproject.com.

Re: [Django] #31858: space outside of parameters are not allowed in path() routes

[Django]

#31858: space outside of parameters are not allowed in path() routes
--+
 Reporter:  Kevin Michel  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (URLs)   |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

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


Comment:

 Yes, you're right. The [https://tools.ietf.org/html/draft-coar-
 cgi-v11-03#section-4.1.5 CGI spec has]:

 > Unlike a URI path, the PATH_INFO is not URL-encoded

 Thanks!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.e19ecfed9a931fd76ad65d8235ff1fd1%40djangoproject.com.

Re: [Django] #31858: space outside of parameters are not allowed in path() routes

[Django]

#31858: space outside of parameters are not allowed in path() routes
--+--
 Reporter:  Kevin Michel  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (URLs)   |  Version:  3.1
 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 Kevin Michel):

 Hi,

 I agree that spaces in URLs are unsafe, and we should urlencode them
 when transmitting or writing URLs, like the browser does automatically.

 However, URLs are urldecoded before reaching the router (which is the
 right thing to do as far as I understand it), the router matches a decoded
 path, which is not really an URL anymore.

 In the WSGI case, the url decoding is done when filling
 `environ['PATH_INFO']`,
 for instance here:
 https://github.com/python/cpython/blob/master/Lib/wsgiref/simple_server.py#L85

 Because of that, it's not possible to try to match the safe "%20" in a
 route
 as if it was an URL.

 I think spaces in URLs are indeed unsafe and invalid but spaces in the
 path for the router are safe and should be allowed.

 Not being able to match all valid paths with a route is a possibility but
 it's
 a bit surprising.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.661f17542f33b4c9ca34105acde2f351%40djangoproject.com.

Re: [Django] #31858: space outside of parameters are not allowed in path() routes

[Django]

#31858: space outside of parameters are not allowed in path() routes
--+--
 Reporter:  Kevin Michel  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (URLs)   |  Version:  3.1
 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
--+--
Changes (by Carlton Gibson):

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


Comment:

 Hi Kevin. Thanks for the report, but I don't think we should support this.

 [https://www.ietf.org/rfc/rfc1738.txt RFC 1738] is pretty clear on this:

 > The space character is unsafe 

 and:

 > ...All unsafe characters must always be encoded within a URL.

 (Search for the "unsafe" section header.)

 I think "If you want to do this nonetheless then use `re_path`" is more
 than reasonable.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.dbbd6f6961baf4ad2ece3599e755c841%40djangoproject.com.

Re: [Django] #31639: F objects do not error when referencing transforms.

[Django]

#31639: F objects do not error when referencing transforms.
-+-
 Reporter:  Baptiste Mispelon|Owner:  Srinivas
 |  Reddy Thatiparthy
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 #31860 was a duplicate using `__date`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.038b8ab1a1e4a86b57e4b55b7ee5cc7f%40djangoproject.com.

Re: [Django] #31860: "__date" in F expression not working, have to use Func()

[Django]

#31860: "__date" in F expression not working, have to use Func()
-+-
 Reporter:  Aleksandr Smechov|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi. I believe this is a duplicate of #31639.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.ffa64a9459d58ffb6ab9258b67d7f8de%40djangoproject.com.

Re: [Django] #24342: Add EnumField model/form fields

[Django]

#24342: Add EnumField model/form fields
-+-
 Reporter:  Thomas Stephenson|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Carlton Gibson):

 #31861 was a duplicate. Maybe the position is advanced some by the enum
 choices available since 3.0.

 Tim's comment:14 stills seems telling: a 3rd-party package showing what's
 feasible is the first/next step, then a discussion of whether to bring
 that into core.
 (Wondering if this is wontfix pending such... 樂)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fa810f4bdba29a520b90adbcea6a5784%40djangoproject.com.

Re: [Django] #31861: Model field for enumeration types

[Django]

#31861: Model field for enumeration types
-+-
 Reporter:  George Sakkis|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  enumeration  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Duplicate of #24342

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.05c740ead52b69822b89ce4618725444%40djangoproject.com.

[Django] #31861: Model field for enumeration types

[Django]

#31861: Model field for enumeration types
-+-
   Reporter:  George |  Owner:  nobody
  Sakkis |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  3.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  enumeration
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The new enumeration types in Django 3.0 are a great addition and
 improvement over the previous choices. On the ORM layer however, only the
 enumeration values are represented, not the enumeration members. I'd like
 to suggest a new `EnumField` custom field that refers to the actual
 enumeration member, similar to how `ForeignKey` fields refers to the
 related model object instead of its primary key (or the `to_field` in
 general). Proposed usage for the
 [https://docs.djangoproject.com/en/3.1/ref/models/fields/#enumeration-
 types Student example]:

 {{{
 #!python
 from django.utils.translation import gettext_lazy as _

 class Student(models.Model):

 class YearInSchool(models.TextChoices):
 FRESHMAN = 'FR', _('Freshman')
 SOPHOMORE = 'SO', _('Sophomore')
 JUNIOR = 'JR', _('Junior')
 SENIOR = 'SR', _('Senior')
 GRADUATE = 'GR', _('Graduate')

 year_in_school = models.EnumField(YearInSchool,
 default=YearInSchool.FRESHMAN)

 def is_upperclass(self):
 return self.year_in_school in {
 self.YearInSchool.JUNIOR,
 self.YearInSchool.SENIOR,
 }
 }}}

 In this case, `Student.year_in_school` would be a `YearInSchool` member,
 not a two-letter string.

 The proposed signature is the following: `class EnumField(enum_type,
 field_type=None, **options)`
 - `enum_type` is the enumeration type, i.e. a `models.Choices` subclass.
 - `field_type` is the underlying ORM field type, e.g. `models.CharField`
 or `models.PositiveSmallIntegerField`.
- In the simplest implementation, this is a required parameter to be
 provided by the caller.
- Alternatively, it could be made optional and inferred based on either
 of the following:
  1. a new optional `field(**options)` staticmethod on the enumeration
 type, if present. For example:
   {{{
   #!python
   class YearInSchool(models.TextChoices):
   FRESHMAN = 'FR', _('Freshman')
   SOPHOMORE = 'SO', _('Sophomore')
   JUNIOR = 'JR', _('Junior')
   SENIOR = 'SR', _('Senior')
   GRADUATE = 'GR', _('Graduate')

   @staticmethod
   def field(**options):
   options.setdefault("max_length", 2)
   return models.Charfield(**options)
   }}}
  2. Automatically based on the type and values of the enumeration
 members:
   - For string values: a `CharField` with `max_length` the maximum
 length of the enumeration values.
   - For integer values: one of {`PositiveSmallIntegerField`,
 `SmallIntegerField`, `PositiveIntegerField`, `IntegerField`,
 `BigIntegerField`}, the smallest that can represent all the enumeration
 values.
   - And so on for other types where there is a natural python type <=>
 ORM field mapping, e.g. `DateField` for date values.
   - If the field type cannot be inferred, raise an appropriate
 exception.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.a20e2e8cd3699ce6a35fc229b29228f7%40djangoproject.com.

Re: [Django] #19040: Allow declaring a model Manager class inside the model class

[Django]

#19040: Allow declaring a model Manager class inside the model class
-+-
 Reporter:  rosensteinniklas@…   |Owner:  (none)
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  model manager| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 After 8 years with no suggestion, I'm going to close this as wontfix. For
 me, Simon's initial reaction was the right one.

 Happy to reconsider if a proposal does turn up, but pending such...

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/084.9eed36307846e0747556a2d78b4fc2b3%40djangoproject.com.

Re: [Django] #27807: Overriding username validators doesn't work as documented

[Django]

#27807: Overriding username validators doesn't work as documented
-+-
 Reporter:  johnrork |Owner:  Shekhar
 |  Nath Gyanwali
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  validation auth  | Triage Stage:  Accepted
  login forms username   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Shekhar Nath Gyanwali):

 Fixed typo, apologies completely missed that 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8ee0aca65a037446f4b387412971f007%40djangoproject.com.