date:20210327

Re: [Django] #32398: Excluding on annotations doesn't apply null handling.

2021-03-27 Thread Django

#32398: Excluding on annotations doesn't apply null handling.
-+-
 Reporter:  Gordon Wrigley   |Owner:  Jordan
 |  Bae
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jordan Bae):

 if anyone has time, please check this
 PR(https://github.com/django/django/pull/14065)

-- 
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.b92a5ba0f0fcb9b6e9f3f2c9f4373d80%40djangoproject.com.

Re: [Django] #32544: Add support for GDAL 3.2 and GEOS 3.9.

2021-03-27 Thread Django

#32544: Add support for GDAL 3.2 and GEOS 3.9.
---+
 Reporter:  Sebastian Kapunkt  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  GIS|  Version:  4.0
 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 Mariusz Felisiak):

 Aapo, thanks for details. Even if the crash is not related to GEOS or GDAL
 versions, this ticket is still valid as we have some tests failures with
 these versions.

-- 
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/074.3542617fb2e802b933e5273e84c2c29f%40djangoproject.com.

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

2021-03-27 Thread Django

#32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU
-+-
 Reporter:  Aapo Rista   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  MultiPoint,  | Triage Stage:
  MultiLinestring, MultiPolygon, |  Unreviewed
  Segmentation fault, GIS,   |
  GeoDjango  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aapo Rista):

 Ok, I found something in Console's Crash Reports (I left out a few hundred
 of lines). See GEOSGeom_createCollection_r there.

 Again, I think this is not GEOS/GDAL/Django **version** related issue (as
 assumed in #32544), but a bug in GEOS/Python/libgeos or something.

 {{{
 Process:   Python [86891]
 Path:
 
/opt/homebrew/*/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
 Identifier:Python
 Version:   3.9.2 (3.9.2)
 Code Type: ARM-64 (Native)
 Parent Process:bash [86834]
 Responsible:   Terminal [1531]
 User ID:   502

 Date/Time: 2021-03-27 16:48:34.731 +0200
 OS Version:macOS 11.2.3 (20D91)
 Report Version:12
 Anonymous UUID:1F81D35A-CC9F-662C-B696-4BC56365499D

 Sleep/Wake UUID:   24C66F23-05FD-4B16-BF9A-9BEF835E38FA

 Time Awake Since Boot: 45 seconds
 Time Since Wake:   6200 seconds

 System Integrity Protection: enabled

 Crashed Thread:0  Dispatch queue: com.apple.main-thread

 Exception Type:EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes:   KERN_INVALID_ADDRESS at 0x00016dda4000
 Exception Note:EXC_CORPSE_NOTIFY

 Termination Signal:Segmentation fault: 11
 Termination Reason:Namespace SIGNAL, Code 0xb
 Terminating Process:   exc handler [86891]

 VM Regions Near 0x16dda4000:
 Stack   16cda4000-16dda4000[ 16.0M] rw-/rwx
 SM=ALI  thread 0
 -->
 Submap  18000-19000[256.0M] r--/r--
 SM=SHM  machine-wide VM submap

 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libgeos_c.1.dylib   0x00010528873c
 GEOSGeom_createCollection_r + 88
 1   libgeos_c.1.dylib   0x00010528872c
 GEOSGeom_createCollection_r + 72
 2   libffi.dylib0x000194e64050 ffi_call_SYSV +
 80
 3   libffi.dylib0x000194e6c9d8 ffi_call_int +
 944
 4   _ctypes.cpython-39-darwin.so0x000103f38684
 _ctypes_callproc + 856
 5   _ctypes.cpython-39-darwin.so0x000103f330f4 PyCFuncPtr_call
 + 220
 6   org.python.python   0x0001024cbbe0 _PyObject_Call
 + 128
 7   org.python.python   0x0001025c2030
 _PyEval_EvalFrameDefault + 40440
 8   org.python.python   0x0001025b7290
 _PyEval_EvalCode + 436
 9   org.python.python   0x0001024cbe7c
 _PyFunction_Vectorcall + 364
 }}}

-- 
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.0916f9ca9a6a1a23b265e2b976254e8f%40djangoproject.com.

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

2021-03-27 Thread Django

#32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU
-+-
 Reporter:  Aapo Rista   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  MultiPoint,  | Triage Stage:
  MultiLinestring, MultiPolygon, |  Unreviewed
  Segmentation fault, GIS,   |
  GeoDjango  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aapo Rista):

 I'm still figuring out how to run catchsegv on Mac Os, but here are the
 rest:

 {{{
 $ python -X faulthandler manage.py shell
 Python 3.9.2 (default, Mar 24 2021, 20:21:37)
 [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from django.contrib.gis.geos import MultiLineString; MultiLineString()
 Fatal Python error: Segmentation fault

 Current thread 0x0001009b7d40 (most recent call first):
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/contrib/gis/geos/prototypes/threadsafe.py", line 49 in
 __call__
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/contrib/gis/geos/libgeos.py", line 152 in __call__
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/contrib/gis/geos/collections.py", line 56 in
 _create_collection
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/contrib/gis/geos/collections.py", line 36 in __init__
   File "", line 1 in 
   File
 
"/opt/homebrew/Cellar/python@3.9/3.9.2_3/Frameworks/Python.framework/Versions/3.9/lib/python3.9/code.py",
 line 90 in runcode
   File
 
"/opt/homebrew/Cellar/python@3.9/3.9.2_3/Frameworks/Python.framework/Versions/3.9/lib/python3.9/code.py",
 line 74 in runsource
   File
 
"/opt/homebrew/Cellar/python@3.9/3.9.2_3/Frameworks/Python.framework/Versions/3.9/lib/python3.9/code.py",
 line 258 in push
   File
 
"/opt/homebrew/Cellar/python@3.9/3.9.2_3/Frameworks/Python.framework/Versions/3.9/lib/python3.9/code.py",
 line 232 in interact
   File
 
"/opt/homebrew/Cellar/python@3.9/3.9.2_3/Frameworks/Python.framework/Versions/3.9/lib/python3.9/code.py",
 line 301 in interact
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/core/management/commands/shell.py", line 82 in python
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/core/management/commands/shell.py", line 100 in handle
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/core/management/base.py", line 398 in execute
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/core/management/base.py", line 354 in run_from_argv
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/core/management/__init__.py", line 413 in execute
   File "/path/to/Project/venv/lib/python3.9/site-
 packages/django/core/management/__init__.py", line 419 in
 execute_from_command_line
   File "/path/to/Project/django_project/mydata/manage.py", line 17 in main
   File "/path/to/Project/django_project/mydata/manage.py", line 21 in
 
 Segmentation fault: 11
 }}}

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

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

Re: [Django] #32544: Add support for GDAL 3.2 and GEOS 3.9.

2021-03-27 Thread Django

#32544: Add support for GDAL 3.2 and GEOS 3.9.
---+
 Reporter:  Sebastian Kapunkt  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  GIS|  Version:  4.0
 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 Aapo Rista):

 I guess this is not related to GEOS or GDAL versions, but M1 CPU
 architecture and the bug is in GEOS. See #32600.

 I've in this Macbook Pro (13-inch, 2017, Intel Core i5) software listed
 below and I've no problems with multi geometries.


 {{{
 $ python manage.py shell
 Python 3.9.2 (default, Feb 24 2021, 13:26:09)
 [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from django.contrib.gis.geos import MultiPolygon
 >>> MultiPolygon()
 
 }}}

 My new Macbook Air (M1, 2020) throws Segmentation fault 11 (as seen in
 #32600).

 $ geos-config --version
 3.9.1

 $ gdalinfo --version
 GDAL 3.2.2, released 2021/03/05

 $ python -V
 Python 3.9.2

 $ uname -a
 Darwin mymac.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21
 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64

-- 
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/074.560bcd1b09d7ae54fdd431850e10693c%40djangoproject.com.

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

2021-03-27 Thread Django

#32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU
-+-
 Reporter:  Aapo Rista   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  MultiPoint,  | Triage Stage:
  MultiLinestring, MultiPolygon, |  Unreviewed
  Segmentation fault, GIS,   |
  GeoDjango  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Can you enable `faulthandler` and check the origin of a segmentation
 fault?

 `catchsegv python -X faulthandler script.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.fc326ff9ec412d968d614a64f333e814%40djangoproject.com.

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

2021-03-27 Thread Django

#32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU
-+-
 Reporter:  Aapo Rista   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  MultiPoint,  | Triage Stage:
  MultiLinestring, MultiPolygon, |  Unreviewed
  Segmentation fault, GIS,   |
  GeoDjango  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #32544.

-- 
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.0e794c801d574ebee70616f99d7a2633%40djangoproject.com.

[Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

2021-03-27 Thread Django

#32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU
-+-
   Reporter:  Aapo   |  Owner:  nobody
  Rista  |
   Type:  Bug| Status:  new
  Component:  GIS|Version:  3.2
   Severity:  Normal |   Keywords:  MultiPoint,
 |  MultiLinestring, MultiPolygon,
   Triage Stage: |  Segmentation fault, GIS, GeoDjango
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I got new Macbook Air (M1, 2020) and when I'm trying to use a project
 transferred from previous Intel Macbook Pro, I get Segmentation fault 11
 in functions that use MultiPoint, MultiLinestring or MultiPolygon.

 How to reproduce:

 Create a virtualenv, a Django project and start the shell:

 {{{
 cd /tmp/ && python3 -m venv venv multisegfault && source
 multisegfault/bin/activate && pip install django && django-admin
 startproject segfaulttest && cd segfaulttest && python manage.py shell
 }}}

 Copy paste this line to the shell:

 {{{
 from django.contrib.gis.geos import MultiLineString; MultiLineString()
 }}}

 You should get **Segmentation fault: 11**.

 It may be possible that **GEOSGeom_createCollection_r** causes crash, but
 I don't know how to try it outside Django.

 Libraries are installed using HomeBrew and they have versions:

 Django 3.2rc1 and 3.1.7

 $ gdal-config --version
 3.2.2

 $ geos-config --version
 3.9.1

 $ python -V
 Python 3.9.2

 # SELECT PostGIS_full_version();
 POSTGIS="3.1.1 aaf4c79" [EXTENSION] PGSQL="130" GEOS="3.9.1-CAPI-1.14.2"
 PROJ="7.2.1" LIBXML="2.9.10" LIBJSON="0.15" LIBPROTOBUF="1.3.3"
 WAGYU="0.5.0 (Internal)"

 Everything is good on Intel Macbook Pro (same library versions) and on
 Ubuntu 20.04 (default versions).

-- 
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/049.eadf03367e23ed129fd6ed848f80bc24%40djangoproject.com.

Re: [Django] #32599: django.contrib.auth.forms.py should always refer to User as get_user_model()

2021-03-27 Thread Django

#32599: django.contrib.auth.forms.py should always refer to User as
get_user_model()
---+-
 Reporter:  Joe Michelini  |Owner:  Joe Michelini
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.auth   |  Version:  3.1
 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 Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => duplicate
 * easy:  1 => 0


Comment:

 Duplicate of #28608. This is also a
 [https://docs.djangoproject.com/en/stable/topics/auth/customizing/#custom-
 users-and-the-built-in-auth-forms documented] behavior.

-- 
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/071.decd9c0df3e5b46f2ae1a001a29914c9%40djangoproject.com.

Re: [Django] #32599: django.contrib.auth.forms.py should always refer to User as get_user_model()

2021-03-27 Thread Django

#32599: django.contrib.auth.forms.py should always refer to User as
get_user_model()
---+-
 Reporter:  Joe Michelini  |Owner:  Joe Michelini
 Type:  Uncategorized  |   Status:  assigned
Component:  contrib.auth   |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Description changed by Joe Michelini:

Old description:

> == Inconsistent Reference
>
> In some sections of django.contrib.auth.forms.py, when referring to the
> User model, Django wisely uses get_user_model(), so whether we decide to
> use the built-in User model, extend it, or use our own, we always get the
> right user when importing these forms.
>
> However, in the UserCreationForm for example, Django instead explicitly
> refers to the built-in user found at django.contrib.auth.models.
>
> This causes some forms to work and some forms to fail when using a custom
> or extended User model, even though extending the built-in User model is
> suggested in the Django documentation.
>
> This is an easy fix and would require all forms in
> django.contrib.auth.forms to refer to get_user_model() as opposed to the
> imported built-in User. In the case where a custom User model is not
> being utilized, get_user_model() will automatically refer to the built-in
> User.

New description:

 == Inconsistent Reference

 In some sections of `django.contrib.auth.forms.py`, when referring to the
 User model, Django wisely uses `get_user_model()`, so whether we decide to
 use the built-in User model, extend it, or use our own, we always get the
 right user when importing these forms.

 However, in the `UserCreationForm` for example, Django instead explicitly
 refers to the built-in user found at `django.contrib.auth.models`.

 This causes some forms to work and some forms to fail when using a custom
 or extended User model, even though extending the built-in User model is
 suggested in the Django documentation.

 This is an easy fix and would require all forms in
 `django.contrib.auth.forms` to refer to `get_user_model()` as opposed to
 the imported built-in `User`. In the case where a custom User model is not
 being utilized, `get_user_model()` will automatically refer to the built-
 in User.

 To reproduce:

 1. Start a new Django project and initiate an app.
 2. In `models.py` of your app, sub-class `AbstractUser` by importing it
 from `django.contrib.auth.models`.
 3. In settings.py, add `AUTH_USER_MODEL=yourapp.YourSubClassedUser` (this
 is all standard).

 {{{
 from django.contrib.auth.models import AbstractUser

 class User(AbstractUser):
 pass
 }}}

 4. Register a view and associated url to render a `UserCreationForm`,
 perhaps using `CreateView` or `FormView`.

 {{{
 from django.shortcuts import render
 from .models import User
 from django.contrib.auth.forms import UserCreationForm
 from django.views.generic.edit import FormView, CreateView

 class RegisterView(CreateView):
 model = User
 form_class = UserCreationForm
 template_name = 'users/register.html
 }}}

 5. Render the form in a template, and run migrations for the first time.
 6. Attempt to start the server. This will throw the following error:

 {{{
 AttributeError: Manager isn't available; 'auth.User' has been swapped for
 'users.User'
 }}}

 In the documentation, Django claims that sub-classing the built-in User is
 not only recommended, but that it will behave exactly like the built-in
 User model. Patching `django.contrib.auth.forms.py` would ensure this.

--

-- 
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/071.c030fc0dafb6c0b4b76e35c57629ed8e%40djangoproject.com.

[Django] #32599: django.contrib.auth.forms.py should always refer to User as get_user_model()

2021-03-27 Thread Django

#32599: django.contrib.auth.forms.py should always refer to User as
get_user_model()
-+---
Reporter: Joe Michelini | Owner: Joe Michelini
Type: Uncategorized | Status: assigned
Component: contrib.auth |Version: 3.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-+---
== Inconsistent Reference

In some sections of django.contrib.auth.forms.py, when referring to the
User model, Django wisely uses get_user_model(), so whether we decide to
use the built-in User model, extend it, or use our own, we always get the
right user when importing these forms.

However, in the UserCreationForm for example, Django instead explicitly
refers to the built-in user found at django.contrib.auth.models.

This causes some forms to work and some forms to fail when using a custom
or extended User model, even though extending the built-in User model is
suggested in the Django documentation.

This is an easy fix and would require all forms in
django.contrib.auth.forms to refer to get_user_model() as opposed to the
imported built-in User. In the case where a custom User model is not being
utilized, get_user_model() will automatically refer to the built-in User.

--
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/056.0152276e97b8438e479fc8242f52616b%40djangoproject.com.

Re: [Django] #32598: Issue in models.SlugField

2021-03-27 Thread Django

#32598: Issue in models.SlugField
-+--
 Reporter:  MojixCoder   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  slug | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Mariusz Felisiak):

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


Comment:

 `SlugField.allow_unicode` doesn't impact path converters. It is also
 [https://docs.djangoproject.com/en/3.1/topics/http/urls/#path-converters
 documented] that:

 > ''**slug** - Matches any slug string consisting of **ASCII letters or
 numbers**, plus the hyphen and underscore characters. For example,
 building-your-1st-django-site.''

 You can create a custom path converter or use `re_path()`.

-- 
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.f334bf79172010090216c75ddb562809%40djangoproject.com.

Re: [Django] #29127: Running tagged tests hides any with syntax errors

2021-03-27 Thread Django

#29127: Running tagged tests hides any with syntax errors
-+-
 Reporter:  Kryštof Řeháček  |Owner:  Chris
 |  Jerdonek
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  tests, tagged-   | Triage Stage:  Accepted
  tests, SyntaxError |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14195

-- 
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.0be338bd83bfdce7aef7ad3c930b0c99%40djangoproject.com.

[Django] #32598: Issue in models.SlugField

2021-03-27 Thread Django

#32598: Issue in models.SlugField
---+
   Reporter:  MojixCoder   |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (URLs)  |Version:  3.1
   Severity:  Normal   |   Keywords:  slug
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 After setting allow_unicode=True for a SlugField in Our models we cant
 still use persian slugs because in  it doesn't  accept unicode
 slugs ( take a look at slug regex ).

 path('/', CategoryArticlesView.as_view(), name="category"),
 Reverse for 'category' with arguments '('برنامه-نویسی',)' not found. 1
 pattern(s) tried: ['articles/(?P[-a-zA-Z0-9_]+)/$']

 remember than allow_unicode=True is working fine in SlugField but url
  doesn't accept it

-- 
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.42a5918f4a0cea10f64096bd273b2db1%40djangoproject.com.

Re: [Django] #32398: Excluding on annotations doesn't apply null handling.

Re: [Django] #32544: Add support for GDAL 3.2 and GEOS 3.9.

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

Re: [Django] #32544: Add support for GDAL 3.2 and GEOS 3.9.

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

Re: [Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

[Django] #32600: Multi geometries cause Segmentation fault 11 on Macbook with M1 CPU

Re: [Django] #32599: django.contrib.auth.forms.py should always refer to User as get_user_model()

Re: [Django] #32599: django.contrib.auth.forms.py should always refer to User as get_user_model()

[Django] #32599: django.contrib.auth.forms.py should always refer to User as get_user_model()

Re: [Django] #32598: Issue in models.SlugField

Re: [Django] #29127: Running tagged tests hides any with syntax errors

[Django] #32598: Issue in models.SlugField

14 matches

Site Navigation

Mail list logo

Footer information