date:20220113

Re: [Django] #33414: Diamond inheritance causes duplicated PK error when creating an object, if the primary key field has a default.

2022-01-13 Thread Django

#33414: Diamond inheritance causes duplicated PK error when creating an object, 
if
the primary key field has a default.
-+-
 Reporter:  Yu Li|Owner:  Yu Li
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (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 Simon Charette):

 After a quick investigation it seems like we simply don't have any tests
 covering diamond inheritance model saves.

 The only instance of diamond inheritance I could find in the test suite
 was
 
[https://github.com/django/django/blob/652c68ffeebd510a6f59e1b56b3e007d07683ad8/tests/model_meta/models.py#L144-L158
 in model_meta tests] but this hierarchy of models exists solely for
 `Option` testing purposes.

 Here's what a tentative patch could look like for this issue, it seems to
 be passing the full suite on SQLite at least.

 {{{#!diff
 diff --git a/django/db/models/base.py b/django/db/models/base.py
 index 37f6a3dd58..d363a1ddeb 100644
 --- a/django/db/models/base.py
 +++ b/django/db/models/base.py
 @@ -823,21 +823,29 @@ def save_base(self, raw=False, force_insert=False,

  save_base.alters_data = True

 -def _save_parents(self, cls, using, update_fields):
 +def _save_parents(self, cls, using, update_fields,
 saved_parents=None):
  """Save all the parents of cls using values from self."""
  meta = cls._meta
  inserted = False
 +if saved_parents is None:
 +saved_parents = {}
  for parent, field in meta.parents.items():
  # Make sure the link fields are synced between parent and
 self.
  if (field and getattr(self, parent._meta.pk.attname) is None
 and
  getattr(self, field.attname) is not None):
  setattr(self, parent._meta.pk.attname, getattr(self,
 field.attname))
 -parent_inserted = self._save_parents(cls=parent, using=using,
 update_fields=update_fields)
 -updated = self._save_table(
 -cls=parent, using=using, update_fields=update_fields,
 -force_insert=parent_inserted,
 -)
 -if not updated:
 +if (parent_updated := saved_parents.get(parent)) is None:
 +parent_inserted = self._save_parents(
 +cls=parent, using=using, update_fields=update_fields,
 saved_parents=saved_parents,
 +)
 +updated = self._save_table(
 +cls=parent, using=using, update_fields=update_fields,
 +force_insert=parent_inserted,
 +)
 +if not updated:
 +inserted = True
 +saved_parents[parent] = updated
 +elif not parent_updated:
  inserted = True
  # Set the parent's PK value to self.
  if field:
 diff --git a/tests/model_inheritance/models.py
 b/tests/model_inheritance/models.py
 index fa37e121ea..99ce78a0f0 100644
 --- a/tests/model_inheritance/models.py
 +++ b/tests/model_inheritance/models.py
 @@ -175,3 +175,20 @@ class Child(Parent):

  class GrandChild(Child):
  pass
 +
 +
 +# Diamond inheritance
 +class CommonAncestor(models.Model):
 +pass
 +
 +
 +class FirstParent(CommonAncestor):
 +first_ancestor = models.OneToOneField(CommonAncestor, models.CASCADE,
 primary_key=True, parent_link=True)
 +
 +
 +class SecondParent(CommonAncestor):
 +second_ancestor = models.OneToOneField(CommonAncestor,
 models.CASCADE, primary_key=True, parent_link=True)
 +
 +
 +class CommonChild(FirstParent, SecondParent):
 +pass
 diff --git a/tests/model_inheritance/tests.py
 b/tests/model_inheritance/tests.py
 index 550a297fb3..97fb3e4a78 100644
 --- a/tests/model_inheritance/tests.py
 +++ b/tests/model_inheritance/tests.py
 @@ -7,7 +7,7 @@
  from django.test.utils import CaptureQueriesContext, isolate_apps

  from .models import (
 -Base, Chef, CommonInfo, GrandChild, GrandParent, ItalianRestaurant,
 +Base, Chef, CommonInfo, CommonChild, GrandChild, GrandParent,
 ItalianRestaurant,
  MixinModel, Parent, ParkingLot, Place, Post, Restaurant, Student,
 SubBase,
  Supplier, Title, Worker,
  )
 @@ -150,6 +150,12 @@ def b():
  sql = query['sql']
  self.assertIn('INSERT INTO', sql, sql)

 +def test_create_diamond_mti(self):
 +with

Re: [Django] #33441: Model Field.hash() should be immutable.

2022-01-13 Thread Django

#33441: Model Field.__hash__() should be immutable.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 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 Mariusz Felisiak):

 * status:  new => assigned
 * 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/068.7af726a978bf9fe02548953fc2647209%40djangoproject.com.

Re: [Django] #33441: Model Field.hash() should be immutable. (was: model Field.hash should be immutable)

2022-01-13 Thread Django

#33441: Model Field.__hash__() should be immutable.
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Replying to [comment:3 Adam Johnson]:
 > `__hash__` is never used for equality. The only requirement is that *IF*
 two objects are equal, they have the same hash. There's no problem with
 creating a `__hash__` that always does `return 1` - it will only make its
 use in dictionaries slow.
 >
 > Changing `__hash__` in the PR was unnecessary for the previous fix.

 Right, I missed it. I always find it suspicious when `__hash__()` does not
 match `__eq__()`, but it's probably just me 路, and we have a similar
 solution for `Model`.

 I'm also struggling with finding ''"plenty of uses"'', nevertheless it
 should not block this change .

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

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

Re: [Django] #33440: Cannot escape % character when using gettext(). (was: Cannot escape % character when using gettext)

2022-01-13 Thread Django

#33440: Cannot escape % character when using gettext().
-+-
 Reporter:  Stian Jensen |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  3.2
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Claude Paroz, Ramiro Morales (added)
 * resolution:   => invalid
 * status:  new => closed
 * component:  Uncategorized => Internationalization


Comment:

 #11240 is about a similar issue but with `{% translate %}` template tag.
 The main difference is that by design we don't support %-formatting in `{%
 translate %}` (see [https://code.djangoproject.com/ticket/11240#comment:16
 comment]), which is not the case in `gettext()`. `gettext()` supports
 `%-formatting` and `%o` is a valid conversion type (signed octal value) so
 there is not much we can do. I'd recommend to remove `50%` from translated
 string (it's not something that will change in different languages), e.g.
 {{{
 gettext('This item is %(discount)s off!') % {'discount': '50%'}
 }}}

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

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

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

2022-01-13 Thread Django

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Ayush
 Type:   |  Joshi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ayush Joshi):

 * has_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/064.5dee3d20bf2da856545b9d0660228fe8%40djangoproject.com.

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

2022-01-13 Thread Django

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Ayush
 Type:   |  Joshi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ayush Joshi):

 https://github.com/django/django/pull/15316

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

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

Re: [Django] #22420: Postgresql connections not being dropped between tests?

2022-01-13 Thread Django

#22420: Postgresql connections not being dropped between tests?
---+--
 Reporter:  Matthew Fisher |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  3.0
 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 Ryan Causey):

 I found this code snippet in some old tests I was perusing recently. I
 hope it helps someone.

 {{{#!python
 def close_db_connections(func, *args, **kwargs):
 """
 Decorator to explicitly close db connections during threaded execution

 Note this is necessary to work around:
 https://code.djangoproject.com/ticket/22420
 """

 def _close_db_connections(*args, **kwargs):
 ret = None
 try:
 ret = func(*args, **kwargs)
 finally:
 for conn in connections.all():
 conn.close()
 return ret

 return _close_db_connections

 # This decorator is necessary to work around:
 # https://code.djangoproject.com/ticket/22420
 @close_db_connections
 def create_account():
 """Create an account for the test_user."""
 account = Account(
 name="foo",
 jurisdiction=test_jurisdiction,
 alarm_system_address=test_address,
 alarm_system_user=test_user,
 effective_creation_date=timezone.now().date(),
 )
 account.full_clean()
 account.save()
 return account

 futures = []
 with ThreadPoolExecutor() as executor:
 # Try to run one thousand account creations concurrently.
 for _ in range(1000):
 futures.append(executor.submit(create_account))
 }}}

-- 
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/070.9d43d73a3cb13ca032c2ceb61ef0037a%40djangoproject.com.

Re: [Django] #33434: Browser font resizing doesn’t work in Django admin due to pixel values

2022-01-13 Thread Django

#33434: Browser font resizing doesn’t work in Django admin due to pixel values
-+-
 Reporter:  Thibaud Colas|Owner:  ravi
 |  kunwar
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ux,   | Triage Stage:  Accepted
  wcag, admin, css   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Description changed by Thibaud Colas:

Old description:

> In the Django admin, there are a lot of
> [https://github.com/django/django/search?l=CSS=font-size font size
> definitions in pixels]. This is problematic for users relying on browser
> text resizing, as [https://developer.mozilla.org/en-
> US/docs/Web/CSS/length#absolute_length_units px and other absolute units
> don’t support this]. We should use relative units throughout the project
> instead. For WCAG conformance, not supporting this is a failure of
> [https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html SC 1.4.4
> Resize Text].
>
> Here is an example, using Chrome’s settings on macOS to do a text-only
> zoom:
>
> [[Image(https://code.djangoproject.com/raw-attachment/ticket/33434/font-
> size-resizing-django.gif, alt="Resizing the font size of the Django admin
> via Chrome browser settings. There are no visible changes, apart from the
> LOGOUT link which has been customized to use rem units.")]]
>
> At the very end, I show what we’d expect to see when using `rem` units by
> adding inline styles to the LOGOUT link.
>
> 
>
> == Proposed fix
>
> We should change all font sizes using absolute units to relative ones.
> For Django, the only absolute unit in use is `px`. I’d recommend
> switching those definitions to `rem`, which is the relative unit that’s
> the simplest to reason about. 1 rem is equal to the font size set on the
> `html` element, which is 16px by default.
>
> So I believe fixing this should just be a matter of dividing all `px`
> definitions by 16 and setting in rem. All font-size definitions in the
> admin are in the `.css` files, so it’s straightforward to look for `font-
> size` in those files.
>
> == Proposed additional changes
>
> In addition to the above, I would recommend:
>
> 1. Creating an official CSS code style documentation for Django, under
> [https://docs.djangoproject.com/en/4.0/internals/contributing/writing-
> code/ Writing code]. This would cover considerations like appropriate
> units to use.
> 2. Refactoring all font-size definitions to `rem`, even the ones already
> relative using keywords (`small`), `em`, and % units. This is just
> because `rem` definitions are much simpler to reason about, since the
> sizes are only relative to the `html` root. There are a few cases where
> `em` still have a place but they should be the (very rare) exception.
> 3. Enforcing `px` are never used for `font-size` with
> [https://stylelint.io/ stylelint] running in continuous integration, and
> its [https://stylelint.io/user-guide/rules/list/declaration-property-
> unit-disallowed-list/ declaration-property-unit-disallowed-list] rule.
>
> All of the above would warrant their own separate ticket, so I’m just
> proposing this here for others’ consideration. If there is some
> consensus, please go ahead with opening the corresponding ticket, or I’m
> happy to.

New description:

 In the Django admin, there are a lot of
 [https://github.com/django/django/search?l=CSS=font-size font size
 definitions in pixels]. This is problematic for users relying on browser
 text resizing, as [https://developer.mozilla.org/en-
 US/docs/Web/CSS/length#absolute_length_units px and other absolute units
 don’t support this]. We should use relative units throughout the project
 instead. For WCAG conformance, not supporting this is a failure of
 [https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html SC 1.4.4
 Resize Text].

 Here is an example, using Chrome’s settings on macOS to do a text-only
 zoom:

 [[Image(https://code.djangoproject.com/raw-attachment/ticket/33434/font-
 size-resizing-django.gif, alt="Resizing the font size of the Django admin
 via Chrome browser settings. There are no visible changes, apart from the
 LOGOUT link which has been customized to use rem units.")]]

 At the very end, I show what we’d expect to see when using `rem` units by
 adding inline styles to the LOGOUT link.

 

 == Proposed fix

 We should change all font sizes using absolute units to relative ones. For
 Django, the only absolute unit in use is `px`. I’d recommend switching
 those

Re: [Django] #33441: model Field.hash should be immutable

2022-01-13 Thread Django

#33441: model Field.__hash__ should be immutable
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > But there are plenty of uses for fields in ORM expressions that *might*
 lead one to create references to a field before/after they are assigned to
 a model class.

 Could you go into more detail about this statement? Fields meant to be
 assigned/bound to a model class should all be set after the app setup
 phase and no fields should be bound to a model class after this point so
 I'm struggling to come up with the plenty of uses in ORM expressions you
 are referring to. Just saying that providing concrete examples might help
 your case here.

 Ideally, we'd have a notion of `BoundField(model: Model, field: Field)` to
 avoid having to differentiate between fields attached to models and ones
 that aren't based of `.model` (that's what we do in django.forms for
 example) but that's a large change for sure.

 As for reverting the patch for the `__hash__` part I'm not against it,
 from what I understand and what Adam pointed out it should not break
 anything. If believe strongly that inherited fields should have they own
 `__hash__` then maybe we could simplify this whole thing by having the
 interitance logic ''bump'' `creation_counter` instead?

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

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

Re: [Django] #33437: Add possibility to render fields individually using as_p, a_table and as_ul

2022-01-13 Thread Django

Comment (by David Smith):

Thank you for your proposal. I have a few comments (mainly concerns,
sorry) on this.

The first is that the current `as_` methods are not recommended due to
accessibility concerns see #32339. I don't think we should be adding
additional features to something that we are not willing to recommend,
even if we stop short of removing the due to backward compatibility
concerns. Having said that it could be appropriate if an `as_div()` render
style is introduced.

I wonder about having the same named functions on both the field and the
form. I'd have thought that would lead to some confusion?

I appreciate this is about whole forms rather than fields is I wonder how
far the new template based form rendering API could meet this need.

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

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

Re: [Django] #33441: model Field.hash should be immutable

2022-01-13 Thread Django

Comment (by Adam Johnson):

> As far as I'm aware, fields are quite specific, in a real life they
don't live without models.

Yes the use case is contrived. But there are plenty of uses for fields in
ORM expressions that *might* lead one to create references to a field
before/after they are assigned to a model class.

> We shouldn't consider the same field instance assigned to a different
models as equal.

`__hash__` is never used for equality. The only requirement is that *IF*
two objects are equal, they have the same hash. There's no problem with
creating a `__hash__` that always does `return 1` - it will only make its
use in dictionaries slow.

Changing `__hash__` in the PR was unnecessary for the previous fix. I
believe it came from a misunderstanding around what `__hash__` means.

> IMO the current behavior is expected, we don't want to reintroduce an
issue fixed in 502e75f9ed5476ffe8229109acf0c23999d4b533.

I don't think there's any risk. The PR passes all tests, including the one
introduced, minus the unnecessary `hash()` assertions.

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

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

Re: [Django] #33169: Migrations crashes with long identifiers on MySQL (8.0.26 )

2022-01-13 Thread Django

#33169: Migrations crashes with long identifiers on MySQL (8.0.26 )
-+-
 Reporter:  Awais Qureshi|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  django32,mysql8.0.26   |  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:   => needsinfo


Comment:

 Awais, I cannot reproduce this issue in MySQL 8 or 5.7 you also didn't
 provide a minimum project to reproduce. I don't think you've explained the
 issue in enough detail to confirm a bug in Django. Please reopen the
 ticket if you can debug your issue and provide details about why and where
 Django is at fault.

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

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

Re: [Django] #33169: Migrations crashes with long identifiers on MySQL (8.0.26 )

2022-01-13 Thread Django

#33169: Migrations crashes with long identifiers on MySQL (8.0.26 )
-+-
 Reporter:  Awais Qureshi|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  django32,mysql8.0.26   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Awais Qureshi):

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


Comment:

 I have added all required information. You can consider re-opening this
 issue.

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

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

Re: [Django] #33441: model Field.hash should be immutable

2022-01-13 Thread Django

#33441: model Field.__hash__ should be immutable
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Simon Charette, Ryan Hiebert (added)
 * status:  assigned => closed
 * resolution:   => invalid


Comment:

 As far as I'm aware, fields are quite specific, in a real life they don't
 live without models. Field's hash should change when it's assigned to a
 model, comparing `creation_counter` is not enough. We shouldn't consider
 the same field instance assigned to a different models as equal. IMO the
 current behavior is expected, we don't want to reintroduce an issue fixed
 in 502e75f9ed5476ffe8229109acf0c23999d4b533.

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

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

Re: [Django] #33441: model Field.hash should be immutable

2022-01-13 Thread Django

#33441: model Field.__hash__ should be immutable
-+-
 Reporter:  Adam Johnson |Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Johnson):

 * owner:  nobody => Adam Johnson
 * has_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/068.1843baa5a2b49c5912c14294832b11eb%40djangoproject.com.

[Django] #33441: model Field.hash should be immutable

2022-01-13 Thread Django

#33441: model Field.__hash__ should be immutable
-+-
   Reporter:  Adam   |  Owner:  nobody
  Johnson|
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  dev
  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  |
-+-
 `Field.__hash__` changes value when a field is assigned to a model class.

 This code crashes with an `AssertionError`:

 {{{
 from django.db import models


 f = models.CharField(max_length=200)
 d = {f: 1}


 class Book(models.Model):
 title = f


 assert f in d
 }}}

 The bug was introduced in #31750.

 It's unlikely to have been encountered because there are few use cases to
 put a field in a dict *before* it's assigned to a model class. But I found
 a reason to do so whilst implementing #26472 and the behaviour had me
 stumped for a little.

 IMO we can revert the `__hash__` change from #31750. Objects with the same
 hash are still checked for equality, which was fixed in that ticket. But
 it's bad if an object's hash changes, since it breaks its use in dicts.

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

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

Re: [Django] #26472: Allow finer granularity in the ability to silence checks

2022-01-13 Thread Django

#26472: Allow finer granularity in the ability to silence checks
-+-
 Reporter:  Peter Zsoldos|Owner:  Adam
 |  Johnson
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  dev
  checks)|
 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 Adam Johnson):

 * owner:  nobody => Adam Johnson
 * status:  new => assigned
 * has_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/066.77cc374bd399d3d52e0297e58aefe7df%40djangoproject.com.

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

2022-01-13 Thread Django

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Ayush
 Type:   |  Joshi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_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/064.7fddef2fcecf313186bea61d2f1f0d02%40djangoproject.com.

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

2022-01-13 Thread Django

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Ayush
 Type:   |  Joshi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
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:"827bc0704761f2c985539d98165420d4fcc0d682" 827bc070]:
 {{{
 #!CommitTicketReference repository=""
 revision="827bc0704761f2c985539d98165420d4fcc0d682"
 Refs #28135 -- Refactored out _find_groups()/_get_group_start_end() hooks
 in admindocs.
 }}}

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

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

[Django] #33440: Cannot escape % character when using gettext

2022-01-13 Thread Django

#33440: Cannot escape % character when using gettext
-+
   Reporter:  Stian Jensen   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 Reproduce:
 Write something like `gettext('This item is 50% off!')`

 run ./manage.py makemessages -a

 find the string in the .po file and translate it like this:

 #: templates/test.html:2
 #, python-format
 msgid "This item is 50% off!"
 msgstr "Denne har 50% rabatt!"

 run ./manage.py compilemessages

 get this error message:

 Execution of msgfmt failed: /Users/stiaje/Projects/django-
 backend/app/hyre/locale/nb/LC_MESSAGES/django.po:601: format
 specifications in 'msgid' and 'msgstr' for argument 1 are not the same

 It works if the letter after the percentage is o in all languages, but
 fails otherwise.

 I tried escaping the percentage symbol as %%, but that resulted in %%
 being outputted on runtime.

 I tried using \u00e0 instead, but that gave:

 Execution of msgfmt failed: /Users/stiaje/Projects/django-
 backend/app/hyre/locale/nb/LC_MESSAGES/django.po:980:36: invalid control
 sequence

 I see that a very similar issue has been reported before, but it is
 closed, with a comment saying to open a new issue for followups:
 https://code.djangoproject.com/ticket/11240

 I can make compilemessages work by manually removing python-format from
 the strings with %, but makemessages will just add that back the next time
 I run it.

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

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

Re: [Django] #29708: Deprecate PickleSerializer and move it out of core

2022-01-13 Thread Django

#29708: Deprecate PickleSerializer and move it out of core
-+-
 Reporter:  Alex Gaynor  |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  closed
Component:  contrib.sessions |  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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"45a42aabfa1a86d1806bec93b31ef6ed7ccd51a7" 45a42aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="45a42aabfa1a86d1806bec93b31ef6ed7ccd51a7"
 Fixed #29708 -- Deprecated PickleSerializer.
 }}}

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

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

Re: [Django] #29708: Deprecate PickleSerializer and move it out of core

2022-01-13 Thread Django

#29708: Deprecate PickleSerializer and move it out of core
-+-
 Reporter:  Alex Gaynor  |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sessions |  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"436862787cbdbd68b0ba20ed8c23b295e3679df3" 43686278]:
 {{{
 #!CommitTicketReference repository=""
 revision="436862787cbdbd68b0ba20ed8c23b295e3679df3"
 Refs #29708 -- Made SessionBase store expiry as string.
 }}}

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

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

Re: [Django] #29708: Deprecate PickleSerializer and move it out of core

2022-01-13 Thread Django

#29708: Deprecate PickleSerializer and move it out of core
-+-
 Reporter:  Alex Gaynor  |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sessions |  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c6cb5a0277fce1b87a4b417002289c31f0ee44bc" c6cb5a02]:
 {{{
 #!CommitTicketReference repository=""
 revision="c6cb5a0277fce1b87a4b417002289c31f0ee44bc"
 Refs #29708 -- Stopped inheriting from PickleSerializer by
 RedisSerializer.
 }}}

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

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

Re: [Django] #33435: Subquery.as_sql() generates invalid SQL.

2022-01-13 Thread Django

#33435: Subquery.as_sql() generates invalid SQL.
-+-
 Reporter:  M1ha Shvn|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  subquery, as_sql | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Sounds reasonable to me as well, I'd only suggest we `.clone()` the
 `query` before altering though.

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

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

Re: [Django] #29708: Deprecate PickleSerializer and move it out of core

2022-01-13 Thread Django

#29708: Deprecate PickleSerializer and move it out of core
-+-
 Reporter:  Alex Gaynor  |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sessions |  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 Mariusz Felisiak):

 * 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/062.4141dc4d1e1820702e66323cd6c32770%40djangoproject.com.

Re: [Django] #33439: SMTPAuthenticationError in EmailMessage/EmailMultiAlternatives when using 'Some Name '. (was: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives w

2022-01-13 Thread Django

#33439: SMTPAuthenticationError in EmailMessage/EmailMultiAlternatives when 
using
'Some Name '.
-+-
 Reporter:  Avramo   |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  EmailMessage,| Triage Stage:
  SMTPAuthenticationError,   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 `Customer Service ` is not an acceptable format, you
 should pass `"Customer Service" `. Also, Django is not
 responsible for your SMTP server configuration. If you're having trouble
 understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

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

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

Re: [Django] #33437: Add possibility to render fields individually using as_p, a_table and as_ul

2022-01-13 Thread Django

#33437: Add possibility to render fields individually using as_p, a_table and 
as_ul
--+--
 Reporter:  Christophe Henry  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  4.0
 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
--+--
Changes (by Hrushikesh Vaidya):

 * cc: Hrushikesh Vaidya (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/073.8eeb79d82bb1b6d04bcac3ea79eaea92%40djangoproject.com.

Re: [Django] #33434: Browser font resizing doesn’t work in Django admin due to pixel values

2022-01-13 Thread Django

#33434: Browser font resizing doesn’t work in Django admin due to pixel values
-+-
 Reporter:  Thibaud Colas|Owner:  ravi
 |  kunwar
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ux,   | Triage Stage:  Accepted
  wcag, admin, css   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by ravi kunwar):

 * owner:  nobody => ravi kunwar
 * 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/070.2b5d7b25d5cafec603414f7286ea4aa8%40djangoproject.com.

Re: [Django] #33439: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when using 'Some Name ' format for `from_email` while running server locally

2022-01-13 Thread Django

#33439: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when
using 'Some Name '  format for `from_email` while running
server locally
-+-
 Reporter:  Avramo   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  EmailMessage,| Triage Stage:
  SMTPAuthenticationError,   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Avramo):

 * owner:  Avramo => (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/064.25f1233f3deb6335ddb6b7182834b5bb%40djangoproject.com.

Re: [Django] #33439: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when using 'Some Name ' format for `from_email` while running server locally

2022-01-13 Thread Django

#33439: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when
using 'Some Name '  format for `from_email` while running
server locally
-+-
 Reporter:  Avramo   |Owner:  Avramo
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  EmailMessage,| Triage Stage:
  SMTPAuthenticationError,   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Avramo):

 * owner:  nobody => Avramo
 * 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/064.e4a72f556a5f18f2238e7c8b1b1b4a81%40djangoproject.com.

Re: [Django] #33438: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when using 'Some Name ' format for `from_email` while running server locally

2022-01-13 Thread Django

#33438: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when
using 'Some Name '  format for `from_email` while running
server locally
-+-
 Reporter:  Avramo   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Mail)  |  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  EmailMessage,| Triage Stage:
  SMTPAuthenticationError,   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Avramo):

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


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

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

[Django] #33439: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when using 'Some Name ' format for `from_email` while running server locally

2022-01-13 Thread Django

#33439: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when
using 'Some Name '  format for `from_email` while running
server locally
-+-
   Reporter:  Avramo |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core   |Version:  2.2
  (Mail) |   Keywords:  EmailMessage,
   Severity:  Normal |  SMTPAuthenticationError,
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Here are my configuations:

 ''.env''
 {{{
 EMAIL_HOST_USER = 'm...@gmail.com'
 }}}


 ''settings.py
 ''
 {{{
 EMAIL_HOST_USER = os.getenv("EMAIL_HOST_USER")
 }}}


 This works just fine normally.

 My issue is when I want to add a name to ''from_email'' using the accepted
 format:[https://docs.djangoproject.com/en/4.0/topics/email/#emailmessage-
 objects]
 ie: "Customer Service " so the recipient sees 'Customer
 Service' instead of just 'fred' or fred@... like this:

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   email = EmailMultiAlternatives(
 subject='subject msg',
 body='testing',
 from_email=f'Customer Service <{settings.EMAIL_HOST_USER}>',
 to=[request.user.email],
 )
 email.attach_alternative(render_to_string('Campaign_Email_NEW.html'),
 "text/html")
 email.send()
   }}}
 }}}

 I tired this in the shell of my live server and it worked!

 BUT when I tried to run this in the shell or via postman when running the
 server locally on my computer then I get a SMTPAuthenticationError, with
 this info:

 {{{
 Exception Type: SMTPAuthenticationError at /api/campaign_mail/
 Exception Value: (535, b'5.7.8 Username and Password not accepted. Learn
 more at\n5.7.8  https://support.google.com/mail/?p=BadCredentials
 i3sm1161703wrn.11 - gsmtp')
 }}}

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

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

[Django] #33438: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when using 'Some Name ' format for `from_email` while running server locally

2022-01-13 Thread Django

#33438: SMTPAuthenticationError in EmailMessage and EmailMultiAlternatives when
using 'Some Name '  format for `from_email` while running
server locally
-+-
   Reporter:  Avramo |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Core   |Version:  2.2
  (Mail) |   Keywords:  EmailMessage,
   Severity:  Normal |  SMTPAuthenticationError,
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Here are my configuations:

 ''.env''
 {{{
 EMAIL_HOST_USER = 'm...@gmail.com'
 }}}


 ''settings.py
 ''
 {{{
 EMAIL_HOST_USER = os.getenv("EMAIL_HOST_USER")
 }}}


 This works just fine normally.

 My issue is when I want to add a name to ''from_email'' using the accepted
 format:[https://docs.djangoproject.com/en/4.0/topics/email/#emailmessage-
 objects]
 ie: "Customer Service " so the recipient sees 'Customer
 Service' instead of just 'fred' or fred@... like this:

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   email = EmailMultiAlternatives(
 subject='subject msg',
 body='testing',
 from_email=f'Customer Service <{settings.EMAIL_HOST_USER}>',
 to=[request.user.email],
 )
 email.attach_alternative(render_to_string('Campaign_Email_NEW.html'),
 "text/html")
 email.send()
   }}}
 }}}

 I tired this in the shell of my live server and it worked!

 BUT when I tried to run this in the shell or via postman when running the
 server locally on my computer then I get a SMTPAuthenticationError, with
 this info:

 {{{
 Exception Type: SMTPAuthenticationError at /api/campaign_mail/
 Exception Value: (535, b'5.7.8 Username and Password not accepted. Learn
 more at\n5.7.8  https://support.google.com/mail/?p=BadCredentials
 i3sm1161703wrn.11 - gsmtp')
 }}}

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

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

[Django] #33437: Add possibility to render fields individually using as_p, a_table and as_ul

2022-01-13 Thread Django

#33437: Add possibility to render fields individually using as_p, a_table and 
as_ul
+
   Reporter:  Christophe Henry  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Forms |Version:  4.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 |
+
 Currently, to render a form, there is a choice between rendering the form
 entirely with:

 {{{#!xml
   
 {% csrf_token %}
 {{ form }}
 
   
 }}}

 and the more cumberstone solution of
 [https://docs.djangoproject.com/en/4.0/topics/forms/#rendering-fields-
 manually Rendering fields manually] if you need more flexibility — for
 instance if you need to fieldsets like proposed in #6630:

 {{{#!xml
   
 {% csrf_token %}
 {{ form }}

 
   {{ form.subject.errors }}
   {{ form.subject.label_tag }}
   {{ form.subject }}
 

 
   
 }}}

 What I propose is  a tradeoff where field can be rendered individually
 using this simple syntax:

 {{{#!xml
   
 {% csrf_token %}
 {{ form }}

 {{ form.subject.as_p }}

 
   
 }}}

 I opened [https://github.com/django/django/pull/15313 a proposition PR to
 solve this feature request].

-- 
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/058.aca28a9987511f48370dace6cf096b30%40djangoproject.com.

Re: [Django] #33436: Remove test_restrictions_with_no_joining_columns. (was: Test that is not correct (?))

2022-01-13 Thread Django

#33436: Remove test_restrictions_with_no_joining_columns.
-+-
 Reporter:  raydeal  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => wontfix
 * easy:  1 => 0


Comment:

 Even though the `Join` is not a public API, we agreed in #25064, that
 generating invalid SQL is a bug in this case. I don't see any harm in
 keeping a regression test for #25064.

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

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

[Django] #33436: Test that is not correct (?)

2022-01-13 Thread Django

#33436: Test that is not correct (?)
-+-
   Reporter:  raydeal|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  4.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:  1
  UI/UX:  0  |
-+-
 I am in doubt what this test exactly test:
 tests/foreign_object/test_empty_join.py

 {{{
 
tests/foreign_object/test_empty_join.RestrictedConditionsTests.test_restrictions_with_no_joining_columns
 }}}

 The test was introduced in [https://code.djangoproject.com/ticket/25064
 #25064], [https://code.djangoproject.com/ticket/27392 #27392] tickets and
 two more small changes in test code.

 In my opinion the test doesn't test django functionality important from
 end user point of view or even development. It probably only test the idea
 of the author. Tested model, its relational fields, are fully customised
 not using public ORM API, just overwrite class methods.

 I would suggest to delete the test because it doesn't bring an important
 value to django code quality.

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

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

Re: [Django] #32681: Variable lookup errors are logged rendering the admin index page if subtitle is not defined.

2022-01-13 Thread Django

#32681: Variable lookup errors are logged rendering the admin index page if
subtitle is not defined.
-+-
 Reporter:  Zain Patel   |Owner:  Zain
 |  Patel
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  admin, template  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"0a4a5e5bacc354df3132d0fcf706839c21afb89d" 0a4a5e5]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a4a5e5bacc354df3132d0fcf706839c21afb89d"
 Refs #32681 -- Fixed VariableDoesNotExist when rendering some admin
 template.

 Regression in 84609b3205905097d7d3038d32e6101f012c0619.

 Follow up to 4e5bbb6ef2287126badd32842b239f4a8a7394ca.

 Thanks Sourav Kumar for the report.
 }}}

-- 
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/063.6eb5717fafd9811df0c82a44edeeb91d%40djangoproject.com.

Re: [Django] #33396: Add the ResolverMatch's name to the technical 500 page.

2022-01-13 Thread Django

#33396: Add the ResolverMatch's name to the technical 500 page.
-+-
 Reporter:  Keryn Knight |Owner:
 |  Hrushikesh Vaidya
 Type:  New feature  |   Status:  closed
Component:  Error reporting  |  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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"6815da6e9497a9a630d9f3637a51134d868bcd5b" 6815da6e]:
 {{{
 #!CommitTicketReference repository=""
 revision="6815da6e9497a9a630d9f3637a51134d868bcd5b"
 Fixed #33396 -- Added view name to technical 500 debug 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/067.2da469463f43dc5e98d556ef6d051a6a%40djangoproject.com.

Re: [Django] #33396: Add the ResolverMatch's name to the technical 500 page.

2022-01-13 Thread Django

#33396: Add the ResolverMatch's name to the technical 500 page.
-+-
 Reporter:  Keryn Knight |Owner:
 |  Hrushikesh Vaidya
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"4099e6e73744ef6a609b578020219f6e4647dd7e" 4099e6e7]:
 {{{
 #!CommitTicketReference repository=""
 revision="4099e6e73744ef6a609b578020219f6e4647dd7e"
 Refs #33396 -- Added django.views.debug.get_caller() 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/067.5db1b31bde7592d91c7e7a938811501a%40djangoproject.com.

Re: [Django] #28135: simplify_regex() doesn't handle non-capturing groups

2022-01-13 Thread Django

#28135: simplify_regex() doesn't handle non-capturing groups
-+-
 Reporter:  German M. Bravo  |Owner:  Ayush
 Type:   |  Joshi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Ayush Joshi):

 * needs_better_patch:  1 => 0


Comment:

 Replying to [comment:14 Mariusz Felisiak]:

 Okay I updated that PR to only include feature, I'll create new PR for
 code refactor :thumbsup:.

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

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

Re: [Django] #33435: Subquery.as_sql() generates invalid SQL. (was: Since django 3.0 Subquery.as_sql() generates invalid SQL)

2022-01-13 Thread Django

#33435: Subquery.as_sql() generates invalid SQL.
-+-
 Reporter:  M1ha Shvn|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  subquery, as_sql | 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):

 * cc: Simon Charette (added)
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Sounds reasonable.

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

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

41 matches

Mail list logo