date:20230403

Re: [Django] #33497: Database persistent connections do not work with ASGI in 4.0

2023-04-03 Thread Django

#33497: Database persistent connections do not work with ASGI in 4.0
-+-
 Reporter:  Stenkar  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ASGI, Database,  | Triage Stage:  Accepted
  async  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Rafał Pitoń):

 * cc: Rafał Pitoń (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/01070187495d3e83-e0e2272a-63c5-4a00-a09c-c9e3ee29263a-00%40eu-central-1.amazonses.com.

Re: [Django] #33738: ASGI http.disconnect not handled on requests with body.

2023-04-03 Thread Django

#33738: ASGI http.disconnect not handled on requests with body.
-+-
 Reporter:  Carlton Gibson   |Owner:  Dennis
 |  Chukwunta
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ASGI | 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"1d1ddffc27cd55c011298cd09bfa4de3fa73cf7a" 1d1ddffc]:
 {{{
 #!CommitTicketReference repository=""
 revision="1d1ddffc27cd55c011298cd09bfa4de3fa73cf7a"
 Fixed #33738 -- Allowed handling ASGI http.disconnect in long-lived
 requests.
 }}}

-- 
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/01070187485846da-7a1db9df-aec0-44a8-8bf7-618183193105-00%40eu-central-1.amazonses.com.

Re: [Django] #33817: Use python-oracledb instead of cx-oracle

2023-04-03 Thread Django

#33817: Use python-oracledb instead of cx-oracle
-+-
 Reporter:  Alexander Shishenko  |Owner:  Jingbei
 |  Li
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Ready for checkin => Accepted


Comment:

 Suraj, why did you changed the status? Oracle tests still crash with this
 patch, it's not
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#ready-for-checkin "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/0107018748520c2e-8b00b519-2480-4996-853b-193781b569d3-00%40eu-central-1.amazonses.com.

Re: [Django] #33817: Use python-oracledb instead of cx-oracle

2023-04-03 Thread Django

#33817: Use python-oracledb instead of cx-oracle
-+-
 Reporter:  Alexander Shishenko  |Owner:  Jingbei
 |  Li
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Suraj Shaw):

 * 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/010701874849841d-765b96fc-667d-4c91-b190-69436807cf7e-00%40eu-central-1.amazonses.com.

Re: [Django] #34451: Incorrect exception handling within the django exception handler

2023-04-03 Thread Django

#34451: Incorrect exception handling within the django exception handler
-+
 Reporter:  Michael Galler   |Owner:  Akshat verma
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  4.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 Akshat verma):

 * owner:  nobody => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070187483c3976-6ae1d82b-2b3c-4d86-9d48-9514c9993b5a-00%40eu-central-1.amazonses.com.

Re: [Django] #34060: Creating CheckConstraint on JSONField with __exact lookup on key transforms crashes on Oracle.

2023-04-03 Thread Django

#34060: Creating CheckConstraint on JSONField with __exact lookup on key 
transforms
crashes on Oracle.
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by r4ge):

 No, Trying to setup the oracle once done will update if I found the
 solution.

-- 
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/0107018747ef85d4-89cdda9a-2145-43ee-9cfe-a0ad8204ab44-00%40eu-central-1.amazonses.com.

Re: [Django] #34453: Parameterized raw queries no longer support lists

2023-04-03 Thread Django

#34453: Parameterized raw queries no longer support lists
-+-
 Reporter:  Jonathan |Owner:  nobody
  Tremesaygues   |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  parameterized raw| Triage Stage:
  query  |  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:   => duplicate


Comment:

 Duplicate of #34434.

-- 
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/0107018747e4c71e-0a33cdb1-883b-462e-a07b-644a09a627a6-00%40eu-central-1.amazonses.com.

Re: [Django] #34454: Connection failed with error message "FATAL: password authentication failed for user 'user'"

2023-04-03 Thread Django

Comment (by nainiu):

Replying to [comment:2 Tim Graham]:
> I don't think you've provided enough details to make this ticket
actionable. I guess you will need to debug the issue further or at least
provide a minimal sample project that reproduces the problem. I guess the
issue doesn't occur with pyscopg2?

Yes, this issue does not occur in psycopg2. Currently, I have not found a
stable way to reproduce it, and I have also examined the 'conninfo'
information in psycopg\connection.py and found that it is the same every
time.

After contacting my cloud database provider, they said that the problem
may be caused by an error after connecting to the same container. I
noticed that there is an additional database connection before each error
occurs.

--
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/0107018747b04c77-ce7e3ea7-3ccb-4ff1-b40d-0f67b111db47-00%40eu-central-1.amazonses.com.

Re: [Django] #34454: Connection failed with error message "FATAL: password authentication failed for user 'user'"

2023-04-03 Thread Django

#34454: Connection failed with error message "FATAL: password authentication 
failed
for user 'user'"
-+-
 Reporter:  lajxw|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 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
-+-
Changes (by Tim Graham):

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


Old description:

> I am using psycopg3 package with Django to connect to a PostgreSQL
> database. However, I am experiencing occasional connection failures with
> the following error message:
>
> "Connection failed with error message: FATAL: password authentication
> failed for user 'user'"
>
> The error seems to occur randomly, and I am not sure what is causing it.
> I have double-checked that the username and password specified in the
> DATABASES setting in my Django project are correct and have the necessary
> permissions to access the database.
>
> I am using psycopg3 version 3.1.8 and PostgreSQL version 4.2rc1.
>
> ///This error can occur randomly, and sometimes it can be correctly
> linked to the database

New description:

 I am using psycopg3 package with Django to connect to a PostgreSQL
 database. However, I am experiencing occasional connection failures with
 the following error message:

 "Connection failed with error message: FATAL: password authentication
 failed for user 'user'"

 The error seems to occur randomly, and I am not sure what is causing it. I
 have double-checked that the username and password specified in the
 DATABASES setting in my Django project are correct and have the necessary
 permissions to access the database.

 I am using psycopg3 version 3.1.8 and Django version 4.2rc1.

 ///This error can occur randomly, and sometimes it can be correctly linked
 to the database

--

Comment:

 I don't think you've provided enough details to make this ticket
 actionable. I guess you will need to debug the issue further or at least
 provide a minimal sample project that reproduces the problem. I guess the
 issue doesn't occur with pyscopg2?

-- 
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/01070187476cd123-28a4cb72-3a96-4fe6-9f0f-3d98edb05146-00%40eu-central-1.amazonses.com.

Re: [Django] #34454: Connection failed with error message "FATAL: password authentication failed for user 'user'"

2023-04-03 Thread Django

#34454: Connection failed with error message "FATAL: password authentication 
failed
for user 'user'"
-+-
 Reporter:  lajxw|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by lajxw:

Old description:

> I am using psycopg3 package with Django to connect to a PostgreSQL
> database. However, I am experiencing occasional connection failures with
> the following error message:
>
> "Connection failed with error message: FATAL: password authentication
> failed for user 'user'"
>
> The error seems to occur randomly, and I am not sure what is causing it.
> I have double-checked that the username and password specified in the
> DATABASES setting in my Django project are correct and have the necessary
> permissions to access the database.
>
> I am using psycopg3 version 3.1.8 and PostgreSQL version 4.2rc1.

New description:

 I am using psycopg3 package with Django to connect to a PostgreSQL
 database. However, I am experiencing occasional connection failures with
 the following error message:

 "Connection failed with error message: FATAL: password authentication
 failed for user 'user'"

 The error seems to occur randomly, and I am not sure what is causing it. I
 have double-checked that the username and password specified in the
 DATABASES setting in my Django project are correct and have the necessary
 permissions to access the database.

 I am using psycopg3 version 3.1.8 and PostgreSQL version 4.2rc1.

 ///This error can occur randomly, and sometimes it can be correctly linked
 to the database

--

-- 
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/01070187474dffbd-2e4fa600-f9b6-421c-ae80-655b6e1f4420-00%40eu-central-1.amazonses.com.

[Django] #34454: Connection failed with error message "FATAL: password authentication failed for user 'user'"

2023-04-03 Thread Django

#34454: Connection failed with error message "FATAL: password authentication
failed
for user 'user'"
-+-
Reporter: lajxw | Owner: nobody
Type: Bug| Status: new
Component: Database |Version: 4.2
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 |
-+-
I am using psycopg3 package with Django to connect to a PostgreSQL
database. However, I am experiencing occasional connection failures with
the following error message:

"Connection failed with error message: FATAL: password authentication
failed for user 'user'"

The error seems to occur randomly, and I am not sure what is causing it. I
have double-checked that the username and password specified in the
DATABASES setting in my Django project are correct and have the necessary
permissions to access the database.

I am using psycopg3 version 3.1.8 and PostgreSQL version 4.2rc1.

--
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/01070187474be1f9-00a064f4-a82e-422d-9fa4-02a769eebbee-00%40eu-central-1.amazonses.com.

[Django] #34453: Parameterized raw queries no longer support lists

2023-04-03 Thread Django

#34453: Parameterized raw queries no longer support lists
-+-
   Reporter:  jonathan   |  Owner:  nobody
  Tremesaygues   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.2
  layer (models, ORM)|   Keywords:  parameterized raw
   Severity:  Normal |  query
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 We have some parameterized raw queries that use a list as parameter, like
 this:

 {{{
 from django.db import connection

 with connection.cursor() as cursor:
 cursor.execute(
 "select * from auth_user where id in %s",
 ((1, 2, 3),)
 )
 }}}

 With Django 4.1.7, the code works as expected. But since upgrade to 4.2,
 with have this error:


 {{{
 SyntaxError   Traceback (most recent call
 last)
 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/django/db/backends/utils.py:89, in CursorWrapper._execute(self,
 sql, params, *ignored_wrapper_args)
  88 else:
 ---> 89 return self.cursor.execute(sql, params)

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/psycopg/cursor.py:723, in Cursor.execute(self, query, params,
 prepare, binary)
 722 except e.Error as ex:
 --> 723 raise ex.with_traceback(None)
 724 return self

 SyntaxError: syntax error at or near "'(1,2,3)'"
 LINE 1: select * from auth_user where pk in '(1,2,3)'
 ^

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

 ProgrammingError  Traceback (most recent call
 last)
 Cell In[6], line 2
   1 with connection.cursor() as cursor:
 > 2 cursor.execute("select * from auth_user where pk in %s", ((1,
 2, 3),))
   3 print(cursor.fetchone())

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/django/db/backends/utils.py:102, in
 CursorDebugWrapper.execute(self, sql, params)
 100 def execute(self, sql, params=None):
 101 with self.debug_sql(sql, params,
 use_last_executed_query=True):
 --> 102 return super().execute(sql, params)

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/django/db/backends/utils.py:67, in CursorWrapper.execute(self,
 sql, params)
  66 def execute(self, sql, params=None):
 ---> 67 return self._execute_with_wrappers(
  68 sql, params, many=False, executor=self._execute
  69 )

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/django/db/backends/utils.py:80, in
 CursorWrapper._execute_with_wrappers(self, sql, params, many, executor)
  78 for wrapper in reversed(self.db.execute_wrappers):
  79 executor = functools.partial(wrapper, executor)
 ---> 80 return executor(sql, params, many, context)

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/django/db/backends/utils.py:84, in CursorWrapper._execute(self,
 sql, params, *ignored_wrapper_args)
  82 def _execute(self, sql, params, *ignored_wrapper_args):
  83 self.db.validate_no_broken_transaction()
 ---> 84 with self.db.wrap_database_errors:
  85 if params is None:
  86 # params default might be backend specific.
  87 return self.cursor.execute(sql)

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/django/db/utils.py:91, in DatabaseErrorWrapper.__exit__(self,
 exc_type, exc_value, traceback)
  89 if dj_exc_type not in (DataError, IntegrityError):
  90 self.wrapper.errors_occurred = True
 ---> 91 raise dj_exc_value.with_traceback(traceback) from exc_value

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/django/db/backends/utils.py:89, in CursorWrapper._execute(self,
 sql, params, *ignored_wrapper_args)
  87 return self.cursor.execute(sql)
  88 else:
 ---> 89 return self.cursor.execute(sql, params)

 File ~/projects/webfit/venv/lib/python3.10/site-
 packages/psycopg/cursor.py:723, in Cursor.execute(self, query, params,
 prepare, binary)
 719 self._conn.wait(
 720 self._execute_gen(query, params, prepare=prepare,
 binary=binary)
 721 )
 722 except e.Error as ex:
 --> 723 raise ex.with_traceback(None)
 724 return self

 ProgrammingError: syntax error at or near "'(1,2,3)'"
 LINE 1: select * from auth_user where pk in '(1,2,3)'
 }}}


 I didn’t see any mention to this change in the release note
 (https://docs.djangoproject.com/en/4.2/releases/4.2/).

-- 
Ticket URL: 
Django

Re: [Django] #33738: ASGI http.disconnect not handled on requests with body.

2023-04-03 Thread Django

#33738: ASGI http.disconnect not handled on requests with body.
-+-
 Reporter:  Carlton Gibson   |Owner:  Dennis
 |  Chukwunta
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  ASGI | 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 Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * type:  Bug => New feature
 * 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/010701874700f329-d272095f-607a-43e0-a803-80dfb645a92f-00%40eu-central-1.amazonses.com.

Re: [Django] #14845: Document connection-creation process

2023-04-03 Thread Django

Comment (by Mariusz Felisiak):

Replying to [comment:15 Akshat verma]:
> Replying to [comment:14 Mariusz Felisiak]:
> > Okay but I unable to get your comments. And due to lack of some
information I did so
> And one thing I want to say that the changes commit by me was quite
genuine but I the place I made was wrong so you must suggest me the right
file path in the GitHub repository.

Please don't edit my comments, you're behavior is really inappropriate. I
left at least a few comments with gentle requests before I started
cleaning up after you. If you want to contribute and need help you should
start from [https://docs.djangoproject.com/en/4.2/internals/contributing/
reading docs] and eventually asking questions on
[https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
support channels]. Are you really going to work on 10 tickets at once?
Again, I'd recommend picking one ticket and starting with that.

--
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/0107018746d284ae-8dadbc55-5052-4724-88eb-01b7583fafd2-00%40eu-central-1.amazonses.com.

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

2023-04-03 Thread Django

#30355: Specifying custom manager doesn't work with prefetch
---+
 Reporter:  Kyle Mulka |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Akshat verma):

 * owner:  (none) => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746d18160-ecc1881d-3d94-45af-a930-bdcbee64c027-00%40eu-central-1.amazonses.com.

Re: [Django] #24434: Django Custom Field inherits ForeignKey deconstruct() fails

2023-04-03 Thread Django

#24434: Django Custom Field inherits ForeignKey deconstruct() fails
-+-
 Reporter:  greenbender  |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  deconstruct,migration  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Akshat verma):

 * owner:  (none) => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746cd4388-3287a30d-7f09-4dea-bc6e-42842b015b4a-00%40eu-central-1.amazonses.com.

Re: [Django] #14845: Document connection-creation process

2023-04-03 Thread Django

#14845: Document connection-creation process
-+-
 Reporter:  Christophe Pettus|Owner:  Akshat
 |  verma
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Akshat verma):

 * owner:  nobody => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746ccd8b8-c3b4335d-08dc-4aee-ab66-c713b08bb6cf-00%40eu-central-1.amazonses.com.

Re: [Django] #2750: ManyToManyField ignores 'default' option

2023-04-03 Thread Django

#2750: ManyToManyField ignores 'default' option
-+-
 Reporter:  bangcok_dangerus@…   |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:
  (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 Akshat verma):

 * owner:  (none) => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746cc7ec6-68c93cd9-037f-4a21-9aa1-3cd96c3b2622-00%40eu-central-1.amazonses.com.

Re: [Django] #24076: Query may fail with pytz exception

2023-04-03 Thread Django

#24076: Query may fail with pytz exception
---+
 Reporter:  lvella |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.6
 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 Akshat verma):

 * owner:  nobody => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746cbdb39-804667df-c9b3-4bcb-b939-769d080e7724-00%40eu-central-1.amazonses.com.

Re: [Django] #14845: Document connection-creation process

2023-04-03 Thread Django

#14845: Document connection-creation process
---+
 Reporter:  Christophe Pettus  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  dev
 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 Akshat verma):

 Replying to [comment:14 Mariusz Felisiak]:
 > Okay but I unable to get your comments. And due to lack of some
 information I did so
 And one thing I want to say that the changes commit by me was quite
 genuine but I the place I made was wrong so you must suggest me the rigth
 file path in the  GitHub repository.

-- 
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/0107018746c84837-3ba028ce-54cb-4a6e-95a0-5bed4a425cb4-00%40eu-central-1.amazonses.com.

Re: [Django] #21292: A how-to or tutorial document for using authentication views and forms is needed

2023-04-03 Thread Django

#21292: A how-to or tutorial document for using authentication views and forms 
is
needed
-+
 Reporter:  Daniele Procida  |Owner:  Akshat verma
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Akshat verma):

 * owner:  (none) => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746c34a34-c6554db1-eded-431f-8550-89fc0f421feb-00%40eu-central-1.amazonses.com.

Re: [Django] #24076: Query may fail with pytz exception

2023-04-03 Thread Django

#24076: Query may fail with pytz exception
---+
 Reporter:  lvella |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+
Changes (by Akshat verma):

 * cc: Akshat verma (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * easy:  0 => 1
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * ui_ux:  0 => 1


Old description:

> If I give date object as input to a filter on a DateTimeField field, like
> this:
>
> {{{
> class Ticket(models.Model):
> register_time = models.DateTimeField(auto_now_add=True)
>
> day = datetime.strptime('2014-10-19', '%Y-%m-%d').date()
> Ticket.objects.filter(register_time__gte=day)
> }}}
>
> I may get a pytz.exceptions.NonExistentTimeError exception. The exact
> exception was:
>
> pytz.exceptions.NonExistentTimeError: 2014-10-19 00:00:00
>
> This date is the start of DST in my timezone:
>
> {{{
> TIME_ZONE = 'America/Sao_Paulo'
> }}}
>
> I believe this is a bug because Django tries to convert my input to a
> datetime object before building the query, and in this case, this
> conversion yields an invalid datetime.
>
> This bug seems very related to issue #9596, because in these cases,
> datetime should be converted to date, not the opposite.
>
> A minimal showcase is attached. Unzip and run ./manage.py test

New description:

 If I give date object as input to a filter on a DateTimeField field, like
 this:

 {{{
 class Ticket(models.Model):
 register_time = models.DateTimeField(auto_now_add=True)

 day = datetime.strptime('2014-10-19', '%Y-%m-%d').date()
 Ticket.objects.filter(register_time__gte=day)
 }}}

 I may get a pytz.exceptions.NonExistentTimeError exception. The exact
 exception was:

 pytz.exceptions.NonExistentTimeError: 2014-10-19 00:00:00

 This date is the start of DST in my timezone:

 {{{
 TIME_ZONE = 'America/Sao_Paulo'
 }}}

 I believe this is a bug because Django tries to convert my input to a
 datetime object before building the query, and in this case, this
 conversion yields an invalid datetime.

 This bug seems very related to issue #9596, because in these cases,
 datetime should be converted to date, not the opposite.

 A minimal showcase is attached. Unzip and run ./manage.py test


 # Changes by Akshat verma
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 385, in
 execute_from_command_line
 utility.execute()
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/core/management/__init__.py", line 354, in execute
 django.setup()
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/__init__.py", line 18, in setup
 from django.utils.log import configure_logging
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/utils/log.py", line 10, in 
 from django.views.debug import ExceptionReporter,
 get_exception_reporter_filter
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/views/debug.py", line 10, in 
 from django.http import (HttpResponse, HttpResponseServerError,
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/http/__init__.py", line 4, in 
 from django.http.response import (HttpResponse, StreamingHttpResponse,
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/http/response.py", line 13, in 
 from django.core.serializers.json import DjangoJSONEncoder
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/core/serializers/__init__.py", line 23, in 
 from django.core.serializers.base import SerializerDoesNotExist
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/core/serializers/base.py", line 6, in 
 from django.db import models
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/db/models/__init__.py", line 6, in 
 from django.db.models.query import Q, QuerySet, Prefetch  # NOQA
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/db/models/query.py", line 13, in 
 from django.db.models.fields import AutoField, Empty
   File "/Users/user/.virtualenvs/app/lib/python3.4/site-
 packages/django/db/models/fields/__init__.py", line 15, in 
 from django.db.models.lookups import default_lookups,
 RegisterLookupMixin
   File

Re: [Django] #24076: Query may fail with pytz exception

2023-04-03 Thread Django

#24076: Query may fail with pytz exception
---+
 Reporter:  lvella |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.6
 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 Akshat verma):

 * owner:  nobody => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746a1e8b8-4846296f-bdb5-4b6f-9423-8e3eb1dae8d0-00%40eu-central-1.amazonses.com.

[Django] Batch modify: #2750, #15059, #15396, #24434, #28011, #34451

2023-04-03 Thread Django

Batch modification to #2750, #15059, #15396, #24434, #28011, #34451 by felixxm:


Action: deassign

-- 
Tickets 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/01070187469ca9ca-a8681758-79b2-467f-88ba-e460015bc8c2-00%40eu-central-1.amazonses.com.

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

2023-04-03 Thread Django

#30355: Specifying custom manager doesn't work with prefetch
---+
 Reporter:  Kyle Mulka |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+
Changes (by Akshat verma):

 * cc: Akshat verma (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * easy:  0 => 1
 * has_patch:  0 => 1
 * ui_ux:  0 => 1


Old description:

> When using prefetch and specifying a custom manager to use for a reverse
> relation, Django doesn't filter correctly. Here's an example:
>
> {{{
> class Business(models.Model):
> name = models.CharField(max_length=255)
>
> def approved_reviews(self):
> return self.review_set(manager='approved_reviews').all()
>

> class ApprovedReviewsManager(models.Manager):
> def get_queryset(self):
> return super().get_queryset().filter(status=Review.APPROVED)
>

> class Review(models.Model):
> NEW = 1
> APPROVED = 2
> STATUS_CHOICES = (
> (NEW, 'New'),
> (APPROVED, 'Approved'),
> )
> business = models.ForeignKey(Business)
> text = models.CharField(max_length=255)
> status = models.IntegerField(choices=STATUS_CHOICES, default=NEW)
>
> objects = models.Manager()
> approved_reviews = ApprovedReviewsManager()
>

> class ApprovedReviewsTest(TestCase):
> def test_with_prefetch(self):
> business = Business()
> business.save()
>
> review = Review()
> review.business = business
> review.save()
>
> businesses =
> Business.objects.prefetch_related('review_set').all()
>
> business = businesses[0]
> approved_reviews =
> business.review_set(manager='approved_reviews').all()
>
> self.assertEqual(len(approved_reviews), 0)
> }}}
>
> The full test project is available here:
> https://github.com/mulka/django_prefetch_manager_bug/blob/master/review_site/tests.py

New description:

 When using prefetch and specifying a custom manager to use for a reverse
 relation, Django doesn't filter correctly. Here's an example:

 {{{
 class Business(models.Model):
 name = models.CharField(max_length=255)

 def approved_reviews(self):
 return self.review_set(manager='approved_reviews').all()


 class ApprovedReviewsManager(models.Manager):
 def get_queryset(self):
 return super().get_queryset().filter(status=Review.APPROVED)


 class Review(models.Model):
 NEW = 1
 APPROVED = 2
 STATUS_CHOICES = (
 (NEW, 'New'),
 (APPROVED, 'Approved'),
 )
 business = models.ForeignKey(Business)
 text = models.CharField(max_length=255)
 status = models.IntegerField(choices=STATUS_CHOICES, default=NEW)

 objects = models.Manager()
 approved_reviews = ApprovedReviewsManager()


 class ApprovedReviewsTest(TestCase):
 def test_with_prefetch(self):
 business = Business()
 business.save()

 review = Review()
 review.business = business
 review.save()

 businesses = Business.objects.prefetch_related('review_set').all()

 business = businesses[0]
 approved_reviews =
 business.review_set(manager='approved_reviews').all()

 self.assertEqual(len(approved_reviews), 0)
 }}}

 The full test project is available here:
 
https://github.com/mulka/django_prefetch_manager_bug/blob/master/review_site/tests.py


 #This implementation: by Akshat verma

 class ToppingManager(models.Manager):
 def filter_vegetarian(self):
 return self.filter(is_vegetarian=True)

 #Looks non-standard. docs look like they do a safer method of modifying
 the super-class method for this sort of lazy-eval stuff. #If I rewrite
 your method in that style, it would look like:

 class ToppingManager(models.Manager):
 def filter_vegetarian(self):
 return super(ToppingManager,
 self).get_queryset().filter(is_vegetarian=True)

 #You wouldn't strictly need the super() here, but safer to use it because
 you should know that you want to start with the #models.Manager
 get_queryset method.

--

Comment:

 #This implementation: by Akshat verma

 class ToppingManager(models.Manager):
 def filter_vegetarian(self):
 return self.filter(is_vegetarian=True)

 #Looks non-standard. docs look like they do a safer method of modifying
 the super-class method for this sort of lazy-eval stuff. #If I rewrite
 your method in that style, it would look like:

 class ToppingManager(models.Manager):

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

2023-04-03 Thread Django

#30355: Specifying custom manager doesn't work with prefetch
---+
 Reporter:  Kyle Mulka |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Akshat verma):

 * owner:  (none) => Akshat verma
 * status:  new => assigned


Old description:

> When using prefetch and specifying a custom manager to use for a reverse
> relation, Django doesn't filter correctly. Here's an example:
>
> {{{
> class Business(models.Model):
> name = models.CharField(max_length=255)
>
> def approved_reviews(self):
> return self.review_set(manager='approved_reviews').all()
>

> class ApprovedReviewsManager(models.Manager):
> def get_queryset(self):
> return super().get_queryset().filter(status=Review.APPROVED)
>

> class Review(models.Model):
> NEW = 1
> APPROVED = 2
> STATUS_CHOICES = (
> (NEW, 'New'),
> (APPROVED, 'Approved'),
> )
> business = models.ForeignKey(Business)
> text = models.CharField(max_length=255)
> status = models.IntegerField(choices=STATUS_CHOICES, default=NEW)
>
> objects = models.Manager()
> approved_reviews = ApprovedReviewsManager()
>

> class ApprovedReviewsTest(TestCase):
> def test_with_prefetch(self):
> business = Business()
> business.save()
>
> review = Review()
> review.business = business
> review.save()
>
> businesses =
> Business.objects.prefetch_related('review_set').all()
>
> business = businesses[0]
> approved_reviews =
> business.review_set(manager='approved_reviews').all()
>
> self.assertEqual(len(approved_reviews), 0)
> }}}
>
> The full test project is available here:
> https://github.com/mulka/django_prefetch_manager_bug/blob/master/review_site/tests.py

New description:

 When using prefetch and specifying a custom manager to use for a reverse
 relation, Django doesn't filter correctly. Here's an example:

 {{{
 class Business(models.Model):
 name = models.CharField(max_length=255)

 def approved_reviews(self):
 return self.review_set(manager='approved_reviews').all()


 class ApprovedReviewsManager(models.Manager):
 def get_queryset(self):
 return super().get_queryset().filter(status=Review.APPROVED)


 class Review(models.Model):
 NEW = 1
 APPROVED = 2
 STATUS_CHOICES = (
 (NEW, 'New'),
 (APPROVED, 'Approved'),
 )
 business = models.ForeignKey(Business)
 text = models.CharField(max_length=255)
 status = models.IntegerField(choices=STATUS_CHOICES, default=NEW)

 objects = models.Manager()
 approved_reviews = ApprovedReviewsManager()


 class ApprovedReviewsTest(TestCase):
 def test_with_prefetch(self):
 business = Business()
 business.save()

 review = Review()
 review.business = business
 review.save()

 businesses = Business.objects.prefetch_related('review_set').all()

 business = businesses[0]
 approved_reviews =
 business.review_set(manager='approved_reviews').all()

 self.assertEqual(len(approved_reviews), 0)
 }}}

 The full test project is available here:
 
https://github.com/mulka/django_prefetch_manager_bug/blob/master/review_site/tests.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/0107018746940b7c-75489ec1-f033-458b-aaf4-a21cf952195f-00%40eu-central-1.amazonses.com.

Re: [Django] #28011: Correct Field.hidden docs regarding what fields are hidden

2023-04-03 Thread Django

#28011: Correct Field.hidden docs regarding what fields are hidden
---+
 Reporter:  Tim Graham |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.10
 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):

 Akshat, are you going to work on any of these tickets? you've already
 assigned many of them to yourself. I'd recommend to focus on a single 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/010701874692b4e6-c7be5039-dfff-4dc2-b666-e92b871826d2-00%40eu-central-1.amazonses.com.

Re: [Django] #24434: Django Custom Field inherits ForeignKey deconstruct() fails

2023-04-03 Thread Django

#24434: Django Custom Field inherits ForeignKey deconstruct() fails
-+-
 Reporter:  greenbender  |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  deconstruct,migration  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * easy:  1 => 0
 * needs_docs:  1 => 0
 * has_patch:  1 => 0
 * ui_ux:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070187469125db-b4be9647-8c72-438f-b4f8-860efec77bbb-00%40eu-central-1.amazonses.com.

Re: [Django] #24434: Django Custom Field inherits ForeignKey deconstruct() fails

2023-04-03 Thread Django

#24434: Django Custom Field inherits ForeignKey deconstruct() fails
-+-
 Reporter:  greenbender  |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  deconstruct,migration  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-

Old description:

> When creating a custom field that inherits from ForeignKey and sets the
> to field there are issues with deconstruction.
>
> Simplified example (models.py)
>
> {{{
> from django.db import models
> from django.contrib.auth.models import User
>

> class UserField(models.ForeignKey):
>
> def __init__(self, *args, **kwargs):
> kwargs['to'] = User
> super(UserField, self).__init__(*args, **kwargs)
>
> def deconstruct(self):
> name, path, args, kwargs = super(UserField, self).deconstruct()
> del kwargs['to']
> return name, path, args, kwargs
>

> class FooBar(models.Model):
> user = UserField()
> }}}
>
> When {{{python manage.py makemigrations}}} is run the following exception
> is raised.
>
> {{{
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/__init__.py", line 385, in
> execute_from_command_line
> utility.execute()
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/__init__.py", line 377, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/base.py", line 288, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/base.py", line 338, in execute
> output = self.handle(*args, **options)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/commands/makemigrations.py", line 111, in
> handle
> convert_apps=app_labels or None,
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 40, in changes
> changes = self._detect_changes(convert_apps, graph)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 139, in
> _detect_changes
> self.generate_renamed_models()
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 413, in
> generate_renamed_models
> model_fields_def =
> self.only_relation_agnostic_fields(model_state.fields)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 79, in
> only_relation_agnostic_fields
> del deconstruction[2]['to']
> KeyError: u'to'
> }}}
>
> It can be resolved by not removing the 'to' kwarg during deconstruction,
> however, this obviously leaves the unrequired 'to' kwarg in the
> constructor, as follows:
>
> {{{
> from django.db import models, migrations
> from django.conf import settings
> import bar.models
>

> class Migration(migrations.Migration):
>
> dependencies = [
> migrations.swappable_dependency(settings.AUTH_USER_MODEL),
> ]
>
> operations = [
> migrations.CreateModel(
> name='FooBar',
> fields=[
> ('id', models.AutoField(verbose_name='ID',
> serialize=False, auto_created=True, primary_key=True)),
> ('user',
> bar.models.UserField(to=settings.AUTH_USER_MODEL)),
> ],
> options={
> },
> bases=(models.Model,),
> ),
> ]
> }}}
>
> I've tried a few variations on this (such as supplying User as the first
> arg to the super call), however, the result is much the same or creates
> additional problems.
>
> The solution proposed at ticket:22263 may solve this problem.
>

>
> #When creating a custom field that inherits from ForeignKey and sets the
> to field there are issues with deconstruction.
>
> Simplified example (models.py)
> from django.db import models
> from django.contrib.auth.models import User
>

> class UserField(models.ForeignKey):
>
> def __init__(self, *args, **kwargs):
> kwargs['to'] = User
> super(UserField, self).__init__(*args, **kwargs)
>
> def deconstruct(self):
> name, path, args, kwargs = super(UserField, self).deconstruct()
> del kwargs['to']
> return name, path, args, kwargs
>

> class

Re: [Django] #28011: Correct Field.hidden docs regarding what fields are hidden

2023-04-03 Thread Django

#28011: Correct Field.hidden docs regarding what fields are hidden
---+
 Reporter:  Tim Graham |Owner:  Akshat verma
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.10
 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 Akshat verma):

 * owner:  nobody => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070187468f7d18-cbc7972a-36fd-4b0e-9d28-2da68fa62bd9-00%40eu-central-1.amazonses.com.

Re: [Django] #24434: Django Custom Field inherits ForeignKey deconstruct() fails

2023-04-03 Thread Django

#24434: Django Custom Field inherits ForeignKey deconstruct() fails
-+-
 Reporter:  greenbender  |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  deconstruct,migration  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Akshat verma):

 * cc: Akshat verma (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * easy:  0 => 1
 * has_patch:  0 => 1
 * ui_ux:  0 => 1


Old description:

> When creating a custom field that inherits from ForeignKey and sets the
> to field there are issues with deconstruction.
>
> Simplified example (models.py)
>
> {{{
> from django.db import models
> from django.contrib.auth.models import User
>

> class UserField(models.ForeignKey):
>
> def __init__(self, *args, **kwargs):
> kwargs['to'] = User
> super(UserField, self).__init__(*args, **kwargs)
>
> def deconstruct(self):
> name, path, args, kwargs = super(UserField, self).deconstruct()
> del kwargs['to']
> return name, path, args, kwargs
>

> class FooBar(models.Model):
> user = UserField()
> }}}
>
> When {{{python manage.py makemigrations}}} is run the following exception
> is raised.
>
> {{{
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/__init__.py", line 385, in
> execute_from_command_line
> utility.execute()
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/__init__.py", line 377, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/base.py", line 288, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/base.py", line 338, in execute
> output = self.handle(*args, **options)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/management/commands/makemigrations.py", line 111, in
> handle
> convert_apps=app_labels or None,
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 40, in changes
> changes = self._detect_changes(convert_apps, graph)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 139, in
> _detect_changes
> self.generate_renamed_models()
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 413, in
> generate_renamed_models
> model_fields_def =
> self.only_relation_agnostic_fields(model_state.fields)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/db/migrations/autodetector.py", line 79, in
> only_relation_agnostic_fields
> del deconstruction[2]['to']
> KeyError: u'to'
> }}}
>
> It can be resolved by not removing the 'to' kwarg during deconstruction,
> however, this obviously leaves the unrequired 'to' kwarg in the
> constructor, as follows:
>
> {{{
> from django.db import models, migrations
> from django.conf import settings
> import bar.models
>

> class Migration(migrations.Migration):
>
> dependencies = [
> migrations.swappable_dependency(settings.AUTH_USER_MODEL),
> ]
>
> operations = [
> migrations.CreateModel(
> name='FooBar',
> fields=[
> ('id', models.AutoField(verbose_name='ID',
> serialize=False, auto_created=True, primary_key=True)),
> ('user',
> bar.models.UserField(to=settings.AUTH_USER_MODEL)),
> ],
> options={
> },
> bases=(models.Model,),
> ),
> ]
> }}}
>
> I've tried a few variations on this (such as supplying User as the first
> arg to the super call), however, the result is much the same or creates
> additional problems.
>
> The solution proposed at ticket:22263 may solve this problem.

New description:

 When creating a custom field that inherits from ForeignKey and sets the to
 field there are issues with deconstruction.

 Simplified example (models.py)

 {{{
 from django.db import models
 from django.contrib.auth.models import User


 class UserField(models.ForeignKey):

 def __init__(self, *args, **kwargs):
 kwargs['to'] = User
 super(UserField, self).__init__(*args, **kwargs)

 def

Re: [Django] #24434: Django Custom Field inherits ForeignKey deconstruct() fails

2023-04-03 Thread Django

#24434: Django Custom Field inherits ForeignKey deconstruct() fails
-+-
 Reporter:  greenbender  |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  deconstruct,migration  |
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Akshat verma):

 * owner:  nobody => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701874683a015-ff87790a-be68-47da-bbf9-c3ab84d49447-00%40eu-central-1.amazonses.com.

Re: [Django] #14845: Document connection-creation process

2023-04-03 Thread Django

#14845: Document connection-creation process
---+
 Reporter:  Christophe Pettus  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  dev
 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):

 Akshat, again, please stop to change ticket descriptions and put random
 information that is neither helpful nor related with the ticket.

-- 
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/0107018746813f36-db6e15fd-68a8-402b-9ada-7fe3bccf6cf1-00%40eu-central-1.amazonses.com.

Re: [Django] #14845: Document connection-creation process

2023-04-03 Thread Django

#14845: Document connection-creation process
-+-
 Reporter:  Christophe Pettus|Owner:  Akshat
 |  verma
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Akshat verma):

 * status:  new => assigned
 * cc: Akshat verma (added)
 * needs_better_patch:  0 => 1
 * easy:  0 => 1
 * owner:  nobody => Akshat verma
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * ui_ux:  0 => 1


Old description:

> Currently, the actual database connection is created on-demand when a
> cursor is requested. This is great for standard use, but there are
> occasional uses where it would be handy to have the connection open
> before requesting a cursor (for example, if you are doing a raw SQL query
> using the cursor(cursor_factory=) syntax.
>
> The proposal here is to move the connection-creation mechanism to a
> separate public method that both the internal cursor-creation mechanism
> and a client of the connection object could call.

New description:

 Currently, the actual database connection is created on-demand when a
 cursor is requested. This is great for standard use, but there are
 occasional uses where it would be handy to have the connection open before
 requesting a cursor (for example, if you are doing a raw SQL query using
 the cursor(cursor_factory=) syntax.

 The proposal here is to move the connection-creation mechanism to a
 separate public method that both the internal cursor-creation mechanism
 and a client of the connection object could call.

 # in settings.py

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'OPTIONS': {
 'service': 'my_service',
 'passfile': '.my_pgpass',
 },
 }
 }

 #in  .pg_service.conf

 [my_service]
 host=localhost
 user=USER
 dbname=NAME
 port=5432

 #in  .my_pgpass

 localhost:5432:NAME:USER:PASSWORD

--

Comment:

 #changes by Akshat verma
 # in settings.py

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'OPTIONS': {
 'service': 'my_service',
 'passfile': '.my_pgpass',
 },
 }
 }

 #in .pg_service.conf

 [my_service]
 host=localhost
 user=USER
 dbname=NAME
 port=5432

 #in .my_pgpass

 localhost:5432:NAME:USER:PASSWORD

-- 
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/0107018746762653-f62b9c1e-b1ca-4234-8558-55ef95e1708a-00%40eu-central-1.amazonses.com.

Re: [Django] #2750: ManyToManyField ignores 'default' option

2023-04-03 Thread Django

#2750: ManyToManyField ignores 'default' option
-+-
 Reporter:  bangcok_dangerus@…   |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:
  (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 Mariusz Felisiak):

 Akshat, I deleted your comment to restore the ticket description. Please
 don't change ticket descriptions. If you want to work on the ticket and
 propose a patch, do this via GitHub 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/0107018746625c17-9ca069f4-ac8b-4a78-a628-121aca057ce3-00%40eu-central-1.amazonses.com.

Re: [Django] #2750: ManyToManyField ignores 'default' option

2023-04-03 Thread Django

#2750: ManyToManyField ignores 'default' option
-+-
 Reporter:  bangcok_dangerus@…   |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Akshat verma):

 * cc: Akshat verma (added)
 * needs_tests:  0 => 1
 * version:   => 4.2
 * easy:  0 => 1
 * needs_docs:  0 => 1
 * ui_ux:  0 => 1


Old description:

> It doesn't seem possible to use the 'default' option to pre-select values
> in the admin site for a ManyToManyField. I've tried a string value, a
> list of strings, and even (following a recommendation from someone on
> #django) passing a list of the actual objects. It would be nice to either
> have this functionality added or to update the docs to reflect the fact
> that 'default' has no effect on ManyToManyFields.
>
> -Basil

New description:

 It doesn't seem possible to use the 'default' option to pre-select values
 in the admin site for a ManyToManyField. I've tried a string value, a list
 of strings, and even (following a recommendation from someone on #django)
 passing a list of the actual objects. It would be nice to either have this
 functionality added or to update the docs to reflect the fact that
 'default' has no effect on ManyToManyFields.

 -Basil

 #you can override the init of the modelform like:

 def __init__(self, *args, **kwargs):
 if 'initial' not in kwargs:
 kwargs['initial'] = {}
 kwargs['initial'].update(product_template_admin_initial_values())
 super(ProductTemplateAdminForm, self).__init__(*args, **kwargs)
 #But that will not allow to use the request.

 #If you depend on the request you can use the admin
 get_changeform_initial_data

 def get_changeform_initial_data(self, request):
 return {'name': 'custom_initial_value'}

 #You can call a method with the request as argument and return a
 dictionary. the m2m default should be a list

--

Comment:

 #you can override the init of the modelform like:

 def __init__(self, *args, **kwargs):
 if 'initial' not in kwargs:
 kwargs['initial'] = {}
 kwargs['initial'].update(product_template_admin_initial_values())
 super(ProductTemplateAdminForm, self).__init__(*args, **kwargs)

 #But that will not allow to use the request.

 #If you depend on the request you can use the admin
 get_changeform_initial_data

 def get_changeform_initial_data(self, request):
 return {'name': 'custom_initial_value'}

 #You can call a method with the request as argument and return a
 dictionary. the m2m default should be a list

-- 
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/01070187465e00a8-8aafb111-9d3b-467b-8998-a7578419dc7e-00%40eu-central-1.amazonses.com.

Re: [Django] #2750: ManyToManyField ignores 'default' option

2023-04-03 Thread Django

#2750: ManyToManyField ignores 'default' option
-+-
 Reporter:  bangcok_dangerus@…   |Owner:  Akshat
 |  verma
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:
  (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 Akshat verma):

 * owner:  nobody => Akshat verma
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018746555af2-6791cabc-ecb2-4adc-a4cd-49895110f096-00%40eu-central-1.amazonses.com.

Re: [Django] #34431: DateTimeField.input_formats change from Django 3.1 is documented improperly

2023-04-03 Thread Django

#34431: DateTimeField.input_formats change from Django 3.1 is documented 
improperly
-+-
 Reporter:  stefan6419846|Owner:  Edison
 Type:   |  Wang
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 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:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"9ef2625cd51f6f84d6268322b1f8e59b99b35aac" 9ef2625c]:
 {{{
 #!CommitTicketReference repository=""
 revision="9ef2625cd51f6f84d6268322b1f8e59b99b35aac"
 [4.2.x] Fixed #34431 -- Improved
 Date/DateTimeField/TimeField.input_formats docs.

 Backport of cbcc1240e912cfc47cb6ea0c4fe6b4a48f36f7e2 from main
 }}}

-- 
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/0107018745c1b772-beb09982-224e-4d29-a816-b7883445dfd5-00%40eu-central-1.amazonses.com.

Re: [Django] #34431: DateTimeField.input_formats change from Django 3.1 is documented improperly

2023-04-03 Thread Django

#34431: DateTimeField.input_formats change from Django 3.1 is documented 
improperly
-+-
 Reporter:  stefan6419846|Owner:  Edison
 Type:   |  Wang
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"cbcc1240e912cfc47cb6ea0c4fe6b4a48f36f7e2" cbcc1240]:
 {{{
 #!CommitTicketReference repository=""
 revision="cbcc1240e912cfc47cb6ea0c4fe6b4a48f36f7e2"
 Fixed #34431 -- Improved Date/DateTimeField/TimeField.input_formats docs.
 }}}

-- 
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/0107018745c12c9e-4e244e1a-cb1e-41a3-badc-069f43158ca7-00%40eu-central-1.amazonses.com.

Re: [Django] #34451: Incorrect exception handling within the django exception handler

2023-04-03 Thread Django

#34451: Incorrect exception handling within the django exception handler
-+
 Reporter:  Michael Galler   |Owner:  Akshat verma
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  4.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 Mariusz Felisiak):

 * component:  Core (Other) => Error reporting
 * stage:  Unreviewed => Accepted


Comment:

 > If I interpret this correctly, the problem is that the exception handler
 tries to render the 500 page, which imports the urls which leads to the
 same error.

 Tentatively accepted for future investigation. It seems that at least
 `resolve_error_handler()`/`get_caller()` should handle errors when
 checking the URLconf/resolving paths.

-- 
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/0107018745bfd8aa-ce1aee98-3771-45b3-a3e7-3a522a1a53a0-00%40eu-central-1.amazonses.com.

40 matches

Mail list logo