Re: [Django] #29942: viewsource links to contrib.auth.forms not appearing

[Django]

#29942: viewsource links to contrib.auth.forms not appearing
-+-
 Reporter:  Yemar Nevets |Owner:  David
 |  Smith
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by nessita <124304+nessita@…>):

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

Comment:

 In [changeset:"b691accea13da0f703728b1d62657cb7ba87da60" b691acce]:
 {{{#!CommitTicketReference repository=""
 revision="b691accea13da0f703728b1d62657cb7ba87da60"
 Fixed #29942 -- Restored source file linking in docs by using the Sphinx
 linkcode ext.

 Co-authored-by: David Smith 
 Co-authored-by: Natalia <124304+ness...@users.noreply.github.com>
 }}}
-- 
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/0107018f79cb41e4-19a6efbc-cee3-4038-ba9b-b11b5da5f102-00%40eu-central-1.amazonses.com.

Re: [Django] #35454: ArrayField with default throwing a ValidationError on full_clean

[Django]

#35454: ArrayField with default throwing a ValidationError on full_clean
-+-
 Reporter:  hfroot   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  full_clean,  | Triage Stage:
  ArrayField, ValidationError|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

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

Comment:

 The docs on the additional fields from `django.contrib.postgres.fields` I
 think (rightly) assume more basic knowledge about `null`, `blank`, and
 `default`, so I'm reluctant to suggest we re-document those basics on
 `ArrayField`.

 > I fixed the issue by adding blank=True to the ArrayField definition.

 Glad you found the answer.
-- 
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/0107018f796fa28d-3644afb1-001a-44b9-8002-21dfc5a412dd-00%40eu-central-1.amazonses.com.

Re: [Django] #35441: Context autoescape parameter is not documented

[Django]

#35441: Context autoescape parameter is not documented
-+-
 Reporter:  Roman Donchenko  |Owner:  John
 Type:   |  Higgins
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  5.0
 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
-+-
Changes (by John Higgins):

 * needs_better_patch:  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/0107018f78b812e5-f6636a14-ce04-4a59-bd10-3f3bd188c2da-00%40eu-central-1.amazonses.com.

Re: [Django] #29942: viewsource links to contrib.auth.forms not appearing

[Django]

#29942: viewsource links to contrib.auth.forms not appearing
-+-
 Reporter:  Yemar Nevets |Owner:  David
 |  Smith
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * needs_better_patch:  1 => 0
 * 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/0107018f78664234-33239c5a-839d-4b64-8581-0dbe0c894e8b-00%40eu-central-1.amazonses.com.

Re: [Django] #35448: test --debug-sql SQL formatting is applied to more than the query

[Django]

#35448: test --debug-sql SQL formatting is applied to more than the query
-+-
 Reporter:  Tim Graham   |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Jae Hyuck Sa ):

 Replying to [comment:10 Tim Graham]:
 > I don't think we want any solution that involves parsing the output
 using regular expressions. That's too complicated. Why not format the SQL
 before it's added to the logging statement in `db/backends/utils.py`?
 >
 > (Incidentally, I'm working on a MongoDB backend for Django and would
 like to override the formatting since it won't be SQL. If the formatting
 were done there, I could move the formatting to an overridable
 `DatabaseOperations.format_sql()` hook.)

 I also think the regular expression is complicated. I only applied the
 part because I was worried that it would also apply to other logs. Am I
 misunderstanding or missing the overall flow?
-- 
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/0107018f77ddabd1-8a3e8ec6-7d0d-49fc-b41d-1b172739d7a7-00%40eu-central-1.amazonses.com.

Re: [Django] #35406: Using Django models in function type annotations, without dependency to settings.configure()

[Django]

#35406: Using Django models in function type annotations, without dependency to
settings.configure()
-+-
 Reporter:  HTErik   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  models, typing   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HTErik):

 Hi. Thanks for the reply.
 I'm already aware of django-stubs and we are already using it for long
 time with success.
 The difficulty here is not getting mypy to work.

 This is a problem with how Django relies deeply on global state
 initialization with the `settings.configure()`, and how the order of how
 you `import` models vs `configure` Django have significant differences,
 that are not only confusing and unexpected to the average Python
 developer, but also impossible to untangle even for the experienced.

 Whenever one type-annotates a function to take any Django-model as input,
 that infects the entire code base, so all code that even just imports this
 function must be **declared and imported**  *after*  `settings.configure`
 is called.  Otherwise you can not even *import* the function. (Not being
 able to *call* it once the application is running is totally expected)

 Because of this, using django models in an components that are shared
 across multiple services, that all may not be pure `manage.py`
 applications, is today more or less impossible, if you at the same time
 want to support type hinting your application completely.
-- 
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/0107018f77d257d7-79afd397-8e8e-431f-86f4-5c6b366e115e-00%40eu-central-1.amazonses.com.

[Django] #35455: psycopg3 warns about connections not being closed

[Django]

#35455: psycopg3 warns about connections not being closed
-+-
   Reporter:  HTErik |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  5.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  psycopg
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When running
 * a Django 5.0.6 application
 * psycopg 3.1.19
 * with db `"ENGINE": "django.db.backends.postgresql"`
 * with Python warnings as errors enabled

 This occasionally prints following error from psycopg:


 {{{
 ResourceWarning: connection  was deleted while still open. Please use 'with' or
 '.close()' to close the connection
 }}}

 This warning comes from the `__del__`  function in
 `psycopg.connection.BaseConnection`.

 I have no idea how to reproduce this.
 I tried patching psycopg to print a stack trace whenever a connection is
 opened and closed. This tells me that the connection that was deleted
 before being closed, was opened through the following code path:


 {{{
   File "blah.py", line 193, in __heartbeat
 MyModel.objects.bulk_update(items_to_run, ["last_update"])
   File "python3.12/site-packages/django/db/models/manager.py", line 87, in
 manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "python3.12/site-packages/django/db/models/query.py", line 922, in
 bulk_update
 with transaction.atomic(using=self.db, savepoint=False):
   File "python3.12/site-packages/django/db/transaction.py", line 198, in
 __enter__
 if not connection.get_autocommit():
   File "python3.12/site-packages/django/db/backends/base/base.py", line
 450, in get_autocommit
 self.ensure_connection()
   File "python3.12/site-packages/django/utils/asyncio.py", line 26, in
 inner
 return func(*args, **kwargs)
   File "python3.12/site-packages/django/db/backends/base/base.py", line
 275, in ensure_connection
 self.connect()
   File "python3.12/site-packages/django/utils/asyncio.py", line 26, in
 inner
 return func(*args, **kwargs)
   File "python3.12/site-packages/django/db/backends/base/base.py", line
 256, in connect
 self.connection = self.get_new_connection(conn_params)
 }}}
-- 
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/0107018f77c287fd-ccd2d29e-3215-4e15-a9f6-eeca4b37248a-00%40eu-central-1.amazonses.com.

Re: [Django] #35448: test --debug-sql SQL formatting is applied to more than the query

[Django]

#35448: test --debug-sql SQL formatting is applied to more than the query
-+-
 Reporter:  Tim Graham   |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1

Comment:

 I don't think we want any solution that involves parsing the output using
 regular expressions. That's too complicated. Why not format the SQL before
 it's added to the logging statement in `db/backends/utils.py`?

 (Incidentally, I'm working on a MongoDB backend for Django and would like
 to override the formatting since it won't be SQL. If the formatting were
 done there, I could move the formatting to an overridable
 `DatabaseOperations.format_sql()` hook.)
-- 
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/0107018f77c180d0-ed8e61e6-0972-47c9-9e74-bc3111f4f601-00%40eu-central-1.amazonses.com.

Re: [Django] #35454: ArrayField with default throwing a ValidationError on full_clean

[Django]

#35454: ArrayField with default throwing a ValidationError on full_clean
-+-
 Reporter:  hfroot   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  full_clean,  | Triage Stage:
  ArrayField, ValidationError|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by hfroot):

 I fixed the issue by adding `blank=True` to the `ArrayField` definition. I
 see now in the docs

For both string-based and non-string-based fields, you will also need
 to set blank=True if you wish to permit empty values in forms, as the null
 parameter only affects database storage (see blank).

 https://docs.djangoproject.com/en/5.0/ref/models/fields/#null

 Maybe the docs for `blank` and the mention of setting `default=list` in
 the `ArrayField` docs could be updated?
-- 
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/0107018f77bf00bc-ba157dfa-ede3-4359-b387-5486e116104b-00%40eu-central-1.amazonses.com.

[Django] #35454: ArrayField with default throwing a ValidationError on full_clean

[Django]

#35454: ArrayField with default throwing a ValidationError on full_clean
-+-
   Reporter:  hfroot |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  5.0
  layer (models, ORM)|   Keywords:  full_clean,
   Severity:  Normal |  ArrayField, ValidationError
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am attempting to add an ArrayField of IntegerFields to my model with a
 default value of list. I would expect the field to be populated with an
 empty list when the object is created, but when I call full_clean a
 ValidationError is thrown.

 ```
 my_array_field = ArrayField(base_field=models.IntegerField(),
 default=list)
 ...
 obj = MyObject.objects.create()
 obj.full_clean()
 ```

 The error I'm seeing is that the field cannot be empty:

 ```
 django.core.exceptions.ValidationError: {'my_array_field': ['Ce champ ne
 peut pas être vide.']}
 ```

 I saw this ticket : https://forum.djangoproject.com/t/fields-with-db-
 default-fail-on-full-clean/28153 so I attempted to use `db_default=list()`
 and `db_default=[]` alone and in conjunction with `default` but none of it
 seems to work.

 Is this a bug? Am I just defining the default wrong?

 I can't see an example of defining the default in the docs, although it
 does mention it :
 
https://docs.djangoproject.com/en/5.0/ref/contrib/postgres/fields/#django.contrib.postgres.fields.ArrayField.base_field

 I'm on Django 5.0.3
-- 
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/0107018f77b12d18-58f5fd8e-8d5a-4f80-b422-f774f836d6a0-00%40eu-central-1.amazonses.com.

Re: [Django] #35448: test --debug-sql SQL formatting is applied to more than the query

[Django]

#35448: test --debug-sql SQL formatting is applied to more than the query
-+-
 Reporter:  Tim Graham   |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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
-+-
Changes (by Jae Hyuck Sa ):

 * needs_better_patch:  1 => 0
 * needs_tests:  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/0107018f77ae1507-5704409a-5321-4b60-8897-a3ad1d38f309-00%40eu-central-1.amazonses.com.

[Django] #35453: ManyToMany field is a concrete field on the defining side.

[Django]

#35453: ManyToMany field is a concrete field on the defining side.
-+-
   Reporter:  Harro  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  5.0
  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  |
-+-
 Was looking at some relationship bugs in: https://github.com/bmispelon
 /django-model-subquery
 And when trying to fix it ran into the following problem:

 ManyToMany fields are concrete and have a column on the defining side.


 Take the User in django, if I do:

 {{{
 [f.column for f in User._meta.get_fields() if f.concrete]
 }}}

 You see `groups` in there, but it's a ManyToMany so there is no actual
 column called groups in the user table.

 Then I dove into django and actually see django itself use
 `local_concrete_fields` internally a lot, which has all the actual fields
 that have a column.


 Shouldn't the ManyToMany basically not be a concrete field so it actually
 matches what you expect and what the docs say about the field property:
 
https://docs.djangoproject.com/en/5.0/ref/models/fields/#django.db.models.Field.concrete
-- 
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/0107018f77851e1e-46140069-37bc-48b3-84db-26e583a77424-00%40eu-central-1.amazonses.com.

Re: [Django] #28900: QuerySet.values() and values_list() for compound queries fails with annotation.

[Django]

#28900: QuerySet.values() and values_list() for compound queries fails with
annotation.
-+-
 Reporter:  elliott-omosheye |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  union, values| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ontowhee):

 * owner:  ontowhee => (none)
 * status:  assigned => new

-- 
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/0107018f7724f3ca-e670aba9-b918-417c-8c9c-71f975e97177-00%40eu-central-1.amazonses.com.

Re: [Django] #35451: Documentation: Gunicorn deployment should probably mention the usage of a proxy

[Django]

#35451: Documentation: Gunicorn deployment should probably mention the usage of 
a
proxy
--+
 Reporter:  Klaas van Schelven|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  5.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
--+
Changes (by Sarah Boyce):

 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted
 * type:  Uncategorized => Cleanup/optimization

Comment:

 Happy to review improvements here 
-- 
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/0107018f771597e4-890998c5-4b83-4a73-9941-142aa0d77bbc-00%40eu-central-1.amazonses.com.

Re: [Django] #35450: Missing documentation: deploying Django in production behind a proxy.

[Django]

#35450: Missing documentation: deploying Django in production behind a proxy.
--+
 Reporter:  Klaas van Schelven|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  5.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
--+
Changes (by Sarah Boyce):

 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted
 * type:  Uncategorized => Cleanup/optimization

Comment:

 There's need talk that the Django docs should better help with deployment,
 so I would happily review PRs on 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/0107018f7714aefb-a41bd06b-d249-4783-888d-c3ab83797072-00%40eu-central-1.amazonses.com.

Re: [Django] #35452: Unexpected results when Paginator's orphans is equal or higher than the page size (was: There seems to an issue with the doc on django's orphans and its implementation)

[Django]

#35452: Unexpected results when Paginator's orphans is equal or higher than the
page size
-+-
 Reporter:  Strapchay|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  pagination,  | Triage Stage:  Accepted
  paginator  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * summary:
 There seems to an issue with the doc on django's orphans and its
 implementation
 =>
 Unexpected results when Paginator's orphans is equal or higher than
 the page size

-- 
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/0107018f770cd94b-d667ade1-0267-40fe-a253-fcb7b7ec3354-00%40eu-central-1.amazonses.com.

Re: [Django] #35452: There seems to an issue with the doc on django's orphans and its implementation

[Django]

#35452: There seems to an issue with the doc on django's orphans and its
implementation
-+-
 Reporter:  Strapchay|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  pagination,  | Triage Stage:  Accepted
  paginator  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * stage:  Unreviewed => Accepted
 * type:  Bug => Cleanup/optimization
 * version:  5.0 => dev

Comment:

 Hello Strapchay, thank you for your report.

 My initial thinking about this report is that having an `orphans` value
 bigger than the page size does not make sense. Could you share a valid use
 case for that?

 Having said that, I think this ticket is valid in that the code should
 either:
 1. enforce that `orphans` is strictly smaller than the page size
 (`per_page`), or
 2. explicitly document that if `orphans` is equal or higher than
 `per_page`, you'll get unexpected results.

 Reproducers:
 {{{
 >>> from django.core.paginator import Paginator
 >>> p = Paginator([str(i) for i in range(9)], per_page=2, orphans=3)
 >>> for i in range(p.num_pages): print(p.page(i+1).object_list)
 ...
 ['0', '1']
 ['2', '3']
 ['4', '5', '6', '7', '8']
 >>>

 >>> p = Paginator([str(i) for i in range(9)], per_page=2, orphans=5)
 >>> for i in range(p.num_pages): print(p.page(i+1).object_list)
 ...
 ['0', '1']
 ['2', '3', '4', '5', '6', '7', '8']

 >>> p = Paginator([str(i) for i in range(9)], per_page=3, orphans=3)
 >>> for i in range(p.num_pages): print(p.page(i+1).object_list)
 ...
 ['0', '1', '2']
 ['3', '4', '5', '6', '7', '8']
 }}}

 I'm inclined to do option 1 but we'd need to do it with a deprecation path
 in case there are code bases out there misusing the `orphans` value.
-- 
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/0107018f770c1c38-59923da7-4fc6-4cda-9dc0-1e43a802edd5-00%40eu-central-1.amazonses.com.

[Django] #35452: There seems to an issue with the doc on django's orphans and its implementation

[Django]

#35452: There seems to an issue with the doc on django's orphans and its
implementation
-+-
   Reporter:  Strapchay  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core   |Version:  5.0
  (Other)|   Keywords:  pagination,
   Severity:  Normal |  paginator
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The documentation
 
https://docs.djangoproject.com/en/4.2/ref/paginator/#django.core.paginator.Paginator.orphans
 says the orphan would append values which are orphans which don't fit into
 the context of the per_page of the paginator to the last_page of the
 paginator if the remaining values is less than or equal to the specified
 orphan value. However, there seems to be a logical error in how it is
 implemented. The orphan only applies if the specified orphan value is
 exactly the value specified and not lesser. And also in situations where
 the page_size specified is lesser than the orphans, the values of the next
 page including the orphan are instead added to the intial page which
 disregards the pagination.

 So in a situation where i specify a page_size of 2 and have 7 queryset
 data and specified the orphans to be 3, it returns only a single page
 making it returned value 7 and similar if the queryset data is 5 and the
 orphans is 3, however, if i specify the orphans to be 1 the pagination
 behaves as expected
-- 
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/0107018f76c336d2-bc4734da-bd81-472c-b9e7-c26e621442a8-00%40eu-central-1.amazonses.com.

Re: [Django] #35449: SplitArrayField doesn't validate properly with remove_trailing_nulls=True (was: SplitArrayField doesn't validate properly (django.contrib.postgres.forms))

[Django]

#35449: SplitArrayField doesn't validate properly with 
remove_trailing_nulls=True
--+
 Reporter:  Matthijs  |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  4.2
 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 Sarah Boyce):

 * stage:  Unreviewed => Accepted
 * summary:
 SplitArrayField doesn't validate properly
 (django.contrib.postgres.forms)
 =>
 SplitArrayField doesn't validate properly with
 remove_trailing_nulls=True

Comment:

 Thank you! Was able to replicate on main
 Here is a test if someone needs.
 {{{#!diff
 diff --git a/tests/postgres_tests/test_array.py
 b/tests/postgres_tests/test_array.py
 index 386a0afa3a..d45fc1d153 100644
 --- a/tests/postgres_tests/test_array.py
 +++ b/tests/postgres_tests/test_array.py
 @@ -1339,6 +1339,22 @@ class TestSplitFormField(PostgreSQLSimpleTestCase):
  ],
  )

 +def test_invalid_char_length_with_remove_trailing_nulls(self):
 +field = SplitArrayField(
 +forms.CharField(max_length=2),
 +size=3,
 +remove_trailing_nulls=True,
 +)
 +with self.assertRaises(exceptions.ValidationError) as cm:
 +field.clean(["abc", "", ""])
 +self.assertEqual(
 +cm.exception.messages,
 +[
 +"Item 1 in the array did not validate: Ensure this value
 has at most 2 "
 +"characters (it has 3).",
 +],
 +)
 +
  def test_splitarraywidget_value_omitted_from_data(self):
 }}}
-- 
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/0107018f7677d6b3-e3e10fd2-b436-4014-9e48-709c220a4c20-00%40eu-central-1.amazonses.com.

Re: [Django] #35448: test --debug-sql SQL formatting is applied to more than the query

[Django]

#35448: test --debug-sql SQL formatting is applied to more than the query
-+-
 Reporter:  Tim Graham   |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f7648b1cb-9300a60a-83f9-4bec-8294-c46e6a046baa-00%40eu-central-1.amazonses.com.

Re: [Django] #35448: test --debug-sql SQL formatting is applied to more than the query

[Django]

#35448: test --debug-sql SQL formatting is applied to more than the query
-+-
 Reporter:  Tim Graham   |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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 Jae Hyuck Sa ):

 I reverted the
 
[commit(3283120)](https://github.com/django/django/commit/3283120cca5d5eba5c3619612d0de5ad49dcf054)
 to resolving the issue of 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/0107018f764633f3-eb5c8659-ae6a-4a9c-b7f6-3403e2251a3f-00%40eu-central-1.amazonses.com.

Re: [Django] #35448: test --debug-sql SQL formatting is applied to more than the query

[Django]

#35448: test --debug-sql SQL formatting is applied to more than the query
-+-
 Reporter:  Tim Graham   |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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
-+-
Changes (by Jae Hyuck Sa ):

 * needs_better_patch:  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/0107018f76458f04-c8a0ae62-70af-429b-a082-b23d254b8cc6-00%40eu-central-1.amazonses.com.

Re: [Django] #35275: Constraints validation fails on UniqueConstraint using OpClass

[Django]

#35275: Constraints validation fails on UniqueConstraint using OpClass
-+-
 Reporter:  Mathieu Kniewallner  |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce <42296566+sarahboyce@…>):

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

Comment:

 In [changeset:"f030236a86a64a4befd3cc8093e2bbeceef52a31" f030236a]:
 {{{#!CommitTicketReference repository=""
 revision="f030236a86a64a4befd3cc8093e2bbeceef52a31"
 Fixed #35275 -- Fixed Meta.constraints validation crash on
 UniqueConstraint with OpClass().

 This also introduces Expression.constraint_validation_compatible that
 allows specifying that expression should be ignored during a constraint
 validation.
 }}}
-- 
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/0107018f763d3dca-6bf71493-56fa-42ea-ae2b-9f974e38631a-00%40eu-central-1.amazonses.com.

[Django] #35451: Documentation: Gunicorn deployment should probably mention the usage of a proxy

[Django]

#35451: Documentation: Gunicorn deployment should probably mention the usage of 
a
proxy
--+
   Reporter:  Klaas van Schelven  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  5.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 The current
 [https://docs.djangoproject.com/en/5.0/howto/deployment/wsgi/gunicorn/
 documentation for deploying using gunicorn](which happens to be the top
 entry in the list of deployment options) does not mention using gunicorn
 should probably be installed behind a proxy, even though this is the very
 first thing the [https://docs.gunicorn.org/en/latest/deploy.html gunicorn
 deployment documentation itself] says. Since not putting a proxy in front
 is insecure, this is probably good advice to add.

 Given that various specific settings are required (#35450) when setting up
 a proxy, it would be nice to refer those from the same page.
-- 
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/0107018f7627157b-42944802-58c0-4a2e-b9cf-3685d305-00%40eu-central-1.amazonses.com.

[Django] #35450: Missing documentation: deploying Django in production behind a proxy.

[Django]

#35450: Missing documentation: deploying Django in production behind a proxy.
--+
   Reporter:  Klaas van Schelven  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  5.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When Django is deployed behind a proxy (with https), various settings
 _must_ be set for your site to work correctly. Currently, there is no
 single place where these settings are documented. That is, they are
 mentioned in the general docs for settings (with a warning "only do this
 when behind a proxy) but there is no page "how to set up Django behind a
 proxy", which means to do this you must now puzzle various Stack Overflow
 / blog posts together.

 The variables that I could find are `SECURE_PROXY_SSL_HEADER`,
 `USE_X_FORWARDED_HOST` and `USE_X_FORWARDED_PORT` (if the port is not
 included in the host), but there may be more.
-- 
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/0107018f7620f028-d94c0e78-21f0-4196-b34d-10eb7b57ca11-00%40eu-central-1.amazonses.com.

Re: [Django] #35448: test --debug-sql SQL formatting is applied to more than the query

[Django]

#35448: test --debug-sql SQL formatting is applied to more than the query
-+-
 Reporter:  Tim Graham   |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f761c9637-81565ba8-75f1-4cbd-bfbd-9a28b7660c08-00%40eu-central-1.amazonses.com.

[Django] #35449: SplitArrayField doesn't validate properly (django.contrib.postgres.forms)

[Django]

#35449: SplitArrayField doesn't validate properly 
(django.contrib.postgres.forms)
+
   Reporter:  Matthijs  |  Owner:  (none)
   Type:  Bug   | Status:  new
  Component:  contrib.postgres  |Version:  4.2
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I created an {{{ArrayField(models.CharField(), size=3)}}} on one of my
 models and created a form for it using the {{{SplitArrayField}}}. My
 requirements where that the array field was optional to fill in and that
 you could also just fill in one of the CharFields and leave the others
 blank. So according to
 
[https://docs.djangoproject.com/en/4.2/ref/contrib/postgres/forms/#django.contrib.postgres.forms.SplitArrayField.remove_trailing_nulls
 the docs] I was to set the {{{CharField}}} in my {{{SplitArrayField}}} to
 {{{required=True}}} and {{{remove_trailing_nulls=True}}} on the
 {{{SplitArrayField}}}.
 {{{
 SplitArrayField(
 forms.CharField(required=True, max_length=148),
 size=3,
 widget=SplitArrayWidget(forms.TextInput(attrs={'size': '148'}), 3),
 remove_trailing_nulls=True,
 required=False
 )
 }}}

 To my surprise the form did not validate properly and I was able to submit
 inputs that exceeded the {{{max_length}}} specified in my form.
 Looking at the {{{def clean}}} method of the {{{SplitArrayField}}} I
 suspect a problem there.

 {{{
 try:
 cleaned_data.append(self.base_field.clean(item))
 except ValidationError as error:
 errors.append(
 prefix_validation_error(
 error,
 self.error_messages["item_invalid"],
 code="item_invalid",
 params={"nth": index + 1},
 )
 )
 cleaned_data.append(None)
 ...
 }}}

 If there is any {{{ValidationError}}} the error is added to {{{errors}}},
 at the same time {{{None}}} is appended to the {{{cleaned_data}}}.
 This causes issues with the {{{self._remove_trailing_nulls}}} later on.

 {{{
 cleaned_data, null_index = self._remove_trailing_nulls(cleaned_data)
 if null_index is not None:
 errors = errors[:null_index]
 errors = list(filter(None, errors))
 }}}

 {{{cleaned_data}}} is passed to {{{self._remove_trailing_nulls}}} and
 because {{{remove_trailing_nulls=True}}}, {{{null_index}}} will be {{{0}}}
 thus {{{errors}}} is reassigned to an empty list.

 I wrote a test case showcasing this issue:
 {{{
 from django import forms
 from django.contrib.postgres.forms import SplitArrayField

 class TestForm1(forms.Form):
 field = SplitArrayField(
 forms.CharField(max_length=5, required=True),
 size=3,
 remove_trailing_nulls=True,
 required=False,
 )

 class TestForm2(forms.Form):
 field = forms.CharField(max_length=5, required=True)

 class SplitArrayFieldTest(TestCase):
 def test_validation_error(self):
 invalid_value = 'invalid'
 form1 = TestForm1(data={'field': [invalid_value, '', '']})
 form2 = TestForm2(data={'field': invalid_value})

 self.assertFalse(form1.is_valid())  #is_valid() should return
 False, but returns True
 self.assertFalse(form2.is_valid())
 }}}
-- 
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/0107018f761633b8-991d65c0-9681-45fe-a680-2242704c8bc6-00%40eu-central-1.amazonses.com.

Re: [Django] #35275: Constraints validation fails on UniqueConstraint using OpClass

[Django]

#35275: Constraints validation fails on UniqueConstraint using OpClass
-+-
 Reporter:  Mathieu Kniewallner  |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * 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/0107018f75de7046-cbdc54d7-e220-4770-976f-d384ea9b5217-00%40eu-central-1.amazonses.com.

Re: [Django] #10554: Response.set_cookie should allow setting two cookies of the same name.

[Django]

#10554: Response.set_cookie should allow setting two cookies of the same name.
---+
 Reporter:  Jeremy Dunck   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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 Benjamin Vulpes):

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

Comment:

 This is some serious bug necromancy, but hear me out.

 My CDN supports presigned URLs and presigned cookies. Presigned URLs
 negate client-side caching. Their presigned cookie implementation forbids
 specifying more than one approved asset per cookie.

 This forces me to include multiple of these presigned cookies for my CDN's
 domain, with identical names, but paths for each asset, and to rely on the
 browser to use cookies' paths to identify which version of the cookie to
 send along with the request to the CDN.

 Definitely an edge case, but worth bringing up as I can't find an escape
 hatch to force Django to otherwise include cookies with the same name and
 domain, but different 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/0107018f75d23315-87048b78-399c-48f2-ba16-fa7fdea71941-00%40eu-central-1.amazonses.com.