Re: [Django] #32935: Test suite fails with sqlite 3.36 and spatialite 5.

2023-06-17 Thread Django
#32935: Test suite fails with sqlite 3.36 and spatialite 5.
-+--
 Reporter:  David Smith  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Alex Tomkins):

 Replying to [comment:8 S. Andrew Sheppard]:
 > That said, it is fair to argue that initializing a database with Django
 and spatialite 5.0 should result in a full 5.0-compatible schema.
 Fortunately, it appears that the CreateMissingSystemTables method also
 described in that documentation does not break, so it could be used as
 part of the fallback.  Perhaps something like this would be appropriate:

 Just upgraded a project to Django 4.2, and this doesn't work for me -
 running `CreateMissingSystemTables(1)` results in the same problem:

 {{{
 django.db.utils.OperationalError: error in trigger
 ISO_metadata_reference_row_id_value_insert: no such column: rowid
 }}}

 The two workarounds which don't result in errors, your one liner in an
 earlier post:

 {{{
 ./manage.py shell -c "import
 django;django.db.connection.cursor().execute('SELECT
 InitSpatialMetaData(1);')";
 }}}

 Or a custom DatabaseWrapper which extends from the spatialite version:

 {{{
 from django.contrib.gis.db.backends.spatialite import base


 class DatabaseWrapper(base.DatabaseWrapper):
 def prepare_database(self):
 # Workaround for https://code.djangoproject.com/ticket/32935
 with self.cursor() as cursor:
 cursor.execute("PRAGMA table_info(geometry_columns);")
 if cursor.fetchall() == []:
 cursor.execute("SELECT InitSpatialMetaData(1)")
 super().prepare_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/01070188cb1c87f2-aab54ee3-688b-4dfe-8a9d-1a1da90ebd75-00%40eu-central-1.amazonses.com.


Re: [Django] #34663: Documentation Typo

2023-06-17 Thread Django
#34663: Documentation Typo
-+-
 Reporter:  HeartthrobRob|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by HeartthrobRob):

 * 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/01070188cb123bef-a5c45c07-5b44-4857-a1d0-31c0d27d4ab0-00%40eu-central-1.amazonses.com.


[Django] #34663: Documentation Typo

2023-06-17 Thread Django
#34663: Documentation Typo
+
   Reporter:  HeartthrobRob |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  4.2
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+
 "Using Argon2 with Django" section lists the command to install argon-2
 (step 1) as {{{python -m pip install django[argon2]}}}. If this is run as
 written, it will produce the following error: {{{no matches found:
 django[argon2]}}}.

 A small formatting change is required to run successfully. the package
 should be nested in quotation marks instead, so it reads: {{{python -m pip
 install 'django[argon2]'}}}
 This is because the zsh shell uses square brackets for globbing/pattern
 matching, and they need to be escaped if they're part of an argument.

 References:
 1. Django docs:
 https://docs.djangoproject.com/en/4.2/topics/auth/passwords/#using-argon2
 -with-django
 2. Solution outline: https://stackoverflow.com/a/30539963/11790080

-- 
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/01070188cb114599-a755682c-f53b-4d84-9b09-dc0ad153e2af-00%40eu-central-1.amazonses.com.


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

2023-06-17 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
-+-

Comment (by Florian Apolloner):

 @MarkusH: Can you or someone else from ops help out here (another option
 would be to temporarily give me access to the CI boxes again)?

-- 
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/01070188ca3be9d5-2f2bebbe-544d-48e3-8512-5bfeb7a44c01-00%40eu-central-1.amazonses.com.


Re: [Django] #21080: collectstatic post-processing fails for references inside comments

2023-06-17 Thread Django
#21080: collectstatic post-processing fails for references inside comments
-+
 Reporter:  shreyas@…|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  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 Petr Přikryl):

 * cc: Petr Přikryl (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/01070188ca08de18-dcdeb356-00fc-48c5-b439-c9d803da12f6-00%40eu-central-1.amazonses.com.


Re: [Django] #34662: Translation strings of ArrayField length validators depend on wrong ngettext key

2023-06-17 Thread Django
#34662: Translation strings of ArrayField length validators depend on wrong
ngettext key
-+-
 Reporter:  şuayip üzülmez   |Owner:  şuayip
 |  üzülmez
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/16986 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/01070188c9569295-59aacf29-8328-4606-8ca9-08f2d54f70a7-00%40eu-central-1.amazonses.com.


Re: [Django] #34542: Required fields allowed to be blank are not accepted non-interactively using createsuperuser

2023-06-17 Thread Django
#34542: Required fields allowed to be blank are not accepted non-interactively
using createsuperuser
-+-
 Reporter:  Lantizia |Owner:  Anvansh
 |  Singh
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  auth | Triage Stage:  Accepted
  createsuperuser superuser email|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by SyedMa3):

 Replying to [ticket:34542 Lantizia]:
 > I've only encountered Django once before (installing mailman3), but this
 time I was trying to install NetBox and I noticed this sentence in their
 documentation...
 >
 > "Specifying an email address for the user is not required"  (search for
 that line in the URL below for better context)
 >
 > [https://docs.netbox.dev/en/stable/installation/3-netbox/]
 >
 > According to these lines...
 [https://github.com/django/django/blob/main/django/contrib/auth/models.py#L378]
 and
 [https://github.com/django/django/blob/main/django/contrib/auth/models.py#L358]
 >
 > The 'email' field is marked as required, but is also marked in a way to
 allow it to be empty.
 >
 > This section of the code validates required fields when createsuperuser
 is called **interactively**...
 
[https://github.com/django/django/blob/main/django/contrib/auth/management/commands/createsuperuser.py#L143]
 >
 > This section of the code validates required fields when createsuperuser
 is called **non-interactively**...
 
[https://github.com/django/django/blob/main/django/contrib/auth/management/commands/createsuperuser.py#L219]
 >
 > Although required fields are enforced, the **non-interactive** code
 doesn't allow for those to be blank, where blank required fields are
 permitted.  I've tried to set a field like 'email' to blank **non-
 interactively** but nothing works, for example...
 >
 > a) just don't set the email field either through an argument or an
 environment variable... it'll complain it is needed
 > b) set the email field via a variable as just 'DJANGO_SUPERUSER_EMAIL='
 (i.e. setting the variable to null)... it still complains it is needed
 > c) set the email field via an argument of --email '' (i.e. double
 quotes) or --email "" (i.e. double single quotes) or even --email \  (i.e.
 passing a single space)... it still complains it is needed
 >
 > Hope this makes sense :)


 I just tried making a superuser non-interactively using the command

 `python manage.py createsuperuser --email "" --user admin`

 and it works without any error.

 Is this bug still valid? @Lantizia

-- 
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/01070188c941a31b-3caf6cdf-0fd7-401c-bb10-56596e6b0748-00%40eu-central-1.amazonses.com.


Re: [Django] #34654: Post-normalization performed on the Username field leading to the bypass of the whitespace stripping

2023-06-17 Thread Django
#34654: Post-normalization performed on the Username field leading to the 
bypass of
the whitespace stripping
--+
 Reporter:  Sim4n6|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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 Ashutosh singh):

 So what's the best solution 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/01070188c93aacef-2d4cc60d-8d58-490a-b2cd-57ba36766268-00%40eu-central-1.amazonses.com.


Re: [Django] #34661: Peppering user passwords

2023-06-17 Thread Django
#34661: Peppering user passwords
---+--
 Reporter:  Fatih Erikli   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  Version:  4.2
 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
---+--

Comment (by Fatih Erikli):

 Here is an example hasher:
 {{{
 # yourapp.hashers.py
 class PepperedPBKDF2PasswordHasher(PBKDF2PasswordHasher):
 algorithm = "pepperred_pbkdf2_sha256"

 def encode(self, password, salt, iterations=None):
 assert password is not None
 assert salt and '$' not in salt
 iterations = iterations or self.iterations
 hash = pbkdf2(password, salt, iterations, digest=self.digest)
 hash = base64.b64encode(
 hash+settings.PASSWORD_PEPPER).decode('ascii').strip()
 return "%s$%d$%s$%s" % (self.algorithm, iterations, salt, hash)

 }}}

 In settings:

 {{{
 PASSWORD_PEPPER = b'4545randombytes342445'
 PASSWORD_HASHERS = [
 "yourapp.hashers.PepperedPBKDF2PasswordHasher",
 "django.contrib.auth.hashers.PBKDF2PasswordHasher",
 "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",
 "django.contrib.auth.hashers.Argon2PasswordHasher",
 "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",
 "django.contrib.auth.hashers.ScryptPasswordHasher",
 ]
 }}}

 The passwords will break when a pepper is changed. All the peppers should
 be archived with the associated users in case if a pepper secret key is
 exposed to the public. The previous peppers will be needed for logging the
 affected users in (before sending a password change notice, for example).

-- 
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/01070188c9338bbb-51929bc2-4166-4f2d-9273-15e2e1636248-00%40eu-central-1.amazonses.com.


Re: [Django] #34654: Post-normalization performed on the Username field leading to the bypass of the whitespace stripping

2023-06-17 Thread Django
#34654: Post-normalization performed on the Username field leading to the 
bypass of
the whitespace stripping
--+
 Reporter:  Sim4n6|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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 Sim4n6):

 Indeed. Next is my understanding.

 In the strip() function doc
 
https://docs.python.org/3/library/stdtypes.html?highlight=removing%20whitespace#str.strip
 If the intended character is omitted, the function removes the whitespace.

 The problem is that the stripping of the leading and the trailing
 whitespace is performed before the Unicode normalization.
 This case fits the attack "using Unicode encoding to bypass Validation
 logic" : https://capec.mitre.org/data/definitions/71.html

 I have done some initial fuzzing (nothing fancy) the Unicode character
 BRAILLE PATTERN BLANK fits partially the criteria.
 Visually looks like a space. But this one remains the same when
 normalized.

 The idea is there may be a Unicode character that when stripped using the
 strip() function, it does not get removed. But after normalization with
 the NFKC form, it may come back as whitespace.

 If a user is able to set a username with whitespace, it kind of looks a
 bit "fishy". Two usernames "sim4n6" and "sim4n6 " (with a trailing space).

 And also some fuzzing leads to this code points too:

 Code Point: 0xa8 Fuzzed: [ ̈sim4n6 ̈].
 Code Point: 0xaf Fuzzed: [ ̄sim4n6 ̄].
 Code Point: 0xb4 Fuzzed: [ ́sim4n6 ́].
 Code Point: 0xb8 Fuzzed: [ ̧sim4n6 ̧].
 Code Point: 0x2d8 Fuzzed: [ ̆sim4n6 ̆].
 Code Point: 0x2d9 Fuzzed: [ ̇sim4n6 ̇].
 Code Point: 0x2da Fuzzed: [ ̊sim4n6 ̊].
 Code Point: 0x2db Fuzzed: [ ̨sim4n6 ̨].
 Code Point: 0x2dc Fuzzed: [ ̃sim4n6 ̃].
 Code Point: 0x2dd Fuzzed: [ ̋sim4n6 ̋].
 Code Point: 0x37a Fuzzed: [ ͅsim4n6 ͅ].
 Code Point: 0x384 Fuzzed: [ ́sim4n6 ́].
 Code Point: 0x385 Fuzzed: [ ̈́sim4n6 ̈́].
 Code Point: 0x1fbd Fuzzed: [ ̓sim4n6 ̓].
 Code Point: 0x1fbf Fuzzed: [ ̓sim4n6 ̓].
 Code Point: 0x1fc0 Fuzzed: [ ͂sim4n6 ͂].
 Code Point: 0x1fc1 Fuzzed: [ ̈͂sim4n6 ̈͂].
 Code Point: 0x1fcd Fuzzed: [ ̓̀sim4n6 ̓̀].
 Code Point: 0x1fce Fuzzed: [ ̓́sim4n6 ̓́].
 Code Point: 0x1fcf Fuzzed: [ ̓͂sim4n6 ̓͂].
 Code Point: 0x1fdd Fuzzed: [ ̔̀sim4n6 ̔̀].
 Code Point: 0x1fde Fuzzed: [ ̔́sim4n6 ̔́].
 Code Point: 0x1fdf Fuzzed: [ ̔͂sim4n6 ̔͂].
 Code Point: 0x1fed Fuzzed: [ ̈̀sim4n6 ̈̀].
 Code Point: 0x1fee Fuzzed: [ ̈́sim4n6 ̈́].
 Code Point: 0x1ffd Fuzzed: [ ́sim4n6 ́].
 Code Point: 0x1ffe Fuzzed: [ ̔sim4n6 ̔].
 Code Point: 0x2017 Fuzzed: [ ̳sim4n6 ̳].
 Code Point: 0x203e Fuzzed: [ ̅sim4n6 ̅].
 Code Point: 0x309b Fuzzed: [ ゙sim4n6 ゙].
 Code Point: 0x309c Fuzzed: [ ゚sim4n6 ゚].
 Code Point: 0xfc5e Fuzzed: [ ٌّsim4n6 ٌّ].
 Code Point: 0xfc5f Fuzzed: [ ٍّsim4n6 ٍّ].
 Code Point: 0xfc60 Fuzzed: [ َّsim4n6 َّ].
 Code Point: 0xfc61 Fuzzed: [ ُّsim4n6 ُّ].
 Code Point: 0xfc62 Fuzzed: [ ِّsim4n6 ِّ].
 Code Point: 0xfc63 Fuzzed: [ ّٰsim4n6 ّٰ].
 Code Point: 0xfe49 Fuzzed: [ ̅sim4n6 ̅].
 Code Point: 0xfe4a Fuzzed: [ ̅sim4n6 ̅].
 Code Point: 0xfe4b Fuzzed: [ ̅sim4n6 ̅].
 Code Point: 0xfe4c Fuzzed: [ ̅sim4n6 ̅].
 Code Point: 0xfe70 Fuzzed: [ ًsim4n6 ً].
 Code Point: 0xfe72 Fuzzed: [ ٌsim4n6 ٌ].
 Code Point: 0xfe74 Fuzzed: [ ٍsim4n6 ٍ].
 Code Point: 0xfe76 Fuzzed: [ َsim4n6 َ].
 Code Point: 0xfe78 Fuzzed: [ ُsim4n6 ُ].
 Code Point: 0xfe7a Fuzzed: [ ِsim4n6 ِ].
 Code Point: 0xfe7c Fuzzed: [ ّsim4n6 ّ].
 Code Point: 0xfe7e Fuzzed: [ ْsim4n6 ْ].
 Code Point: 0xffe3 Fuzzed: [ ̄sim4n6 ̄].

 Those code points can be used as trailing and leading in usernames and
 result in whitespace, after Unicode normalization the way Django does it.

 char = chr(code_point)
 # Username input with potential trialing and leading
 whitespace
 username = char + "sim4n6" + char
 # this is the way it is done by Django
 s = unicodedata.normalize("NFKC", username.strip())
 if contains_whitespace(s):
 # Print the Unicode character and its code point for
 demonstration purposes
 print(f"Code Point: {hex(code_point)}\tResult: [{s}].")

 With those code points, it is not only visually a space but a regular one.

 Voila

 PS: I wrote about this once: https://sim4n6.beehiiv.com/p/unicode-
 characters-bypass-security-checks

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

-- 
You received this 

[Django] #34662: Translation strings of ArrayField length validators depend on wrong ngettext key

2023-06-17 Thread Django
#34662: Translation strings of ArrayField length validators depend on wrong
ngettext key
-+-
   Reporter:  şuayip |  Owner:  şuayip üzülmez
  üzülmez|
   Type:  Bug| Status:  assigned
  Component: |Version:  dev
  contrib.postgres   |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 It seems that in ArrayMaxLengthValidator and ArrayMinLengthValidator
 ngettext's number argument depends on wrong key.


 Patch: https://github.com/django/django/pull/16986

-- 
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/01070188c8e429a3-f1a11125-3866-450e-89e9-9b572844dd78-00%40eu-central-1.amazonses.com.


Re: [Django] #34657: Testing assertions `assertContains` and `assertInHTML` should output the haystack on failure

2023-06-17 Thread Django
#34657: Testing assertions `assertContains` and `assertInHTML` should output the
haystack on failure
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  HTML, assertions,| Triage Stage:  Accepted
  testing|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:2 Natalia Bidart]:
 > Tentatively accepting because this is related to the testing framework,
 though I'm not 100% sure on procedure whether this specific case needs a
 forum post since it's marked as a new feature. I would argue this is a
 cleanup/optimization :thinking:

 Creating a new setting is always controversial (we already have many of
 them) and users can already control it with `maxDiff`.

-- 
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/01070188c8b5d5f6-2b55770c-a8f2-4137-a0c0-3daef273d1c4-00%40eu-central-1.amazonses.com.


Re: [Django] #34657: Testing assertions `assertContains` and `assertInHTML` should output the haystack on failure

2023-06-17 Thread Django
#34657: Testing assertions `assertContains` and `assertInHTML` should output the
haystack on failure
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  HTML, assertions,| Triage Stage:  Accepted
  testing|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sarah Boyce):

 I can see the value of this. The react testing library we use has a
 setting `DEBUG_PRINT_LIMIT` (https://testing-library.com/docs/dom-testing-
 library/api-debugging/#automatic-logging) with a default of 7000
 characters but you can increase it if you need to see more printed. I
 recommend that we have a similar setting 

-- 
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/01070188c89b35a4-8c609ac0-407d-471d-b3f4-08dce6f6e6db-00%40eu-central-1.amazonses.com.


Re: [Django] #34659: mysql backend creates queries using CONVERT_TZ even when this is not supported

2023-06-17 Thread Django
#34659: mysql backend creates queries using CONVERT_TZ even when this is not
supported
-+-
 Reporter:  Klaas van Schelven   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Klaas van Schelven):

 "silently behaving incorrectly rather than failing explicitly, but
 documented" is an unsatisfactory answer to me, but I do admit that the
 point may be broader than the single weird behavior that I ran into.
 Couldn't we turn this into a django system check or similar?

-- 
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/01070188c88535fd-530a9750-f43b-4196-b26d-ad3cc98642de-00%40eu-central-1.amazonses.com.