Re: [Django] #33312: Errors when trying to clone an object from a deferred queryset

2021-11-23 Thread Django
#33312: Errors when trying to clone an object from a deferred queryset
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Egor R):

 * cc: Egor R (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/065.ea6d12c7fe4433f8894f28247c9ecc98%40djangoproject.com.


Re: [Django] #33314: Migration Fail with MTI and Many2Many relation when switching PK type

2021-11-23 Thread Django
#33314: Migration Fail with MTI and Many2Many relation when switching PK type
-+-
 Reporter:  Philipp  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, MTI, | Triage Stage:
  ManyToMany |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Philipp:

Old description:

> This is somewhat related to #32743 and #32742
>
> Consider the following example:
> A simple inheritance where the child model has a M2M relation to some
> other model:
>

> {{{
> class SomeModel(models.Model):
> some_field = models.IntegerField(default=5)
>

> class BaseModel(models.Model):
> some_other_base_field = models.IntegerField(default=5)
>
> class Meta:
> abstract = False
>
> class DerivedModel(BaseModel):
> relation = models.ManyToManyField(SomeModel, related_name='+')
> }}}
>

> I have altered migration 0001 manually to mimic the create behaviour
> prior to Django 3.2 (AutoField instead of BigAuto for PK)
> The second migration correctly picks up that this needs to be changed.
>
> The resulting sql query for 0002 is:
>
> {{{
> --
> -- Alter field id on basemodel
> --
> ALTER TABLE `sample_derivedmodel` DROP FOREIGN KEY
> `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk_sample_ba`;
> ALTER TABLE `sample_basemodel` MODIFY `id` bigint AUTO_INCREMENT NOT
> NULL;
> ALTER TABLE `sample_derivedmodel` MODIFY `basemodel_ptr_id` bigint NOT
> NULL; <- FAILS
> ALTER TABLE `sample_derivedmodel` ADD CONSTRAINT
> `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk` FOREIGN KEY
> (`basemodel_ptr_id`) REFERENCES `sample_basemodel` (`id`);
> --
> -- Alter field id on somemodel
> --
> ALTER TABLE `sample_derivedmodel_relation` DROP FOREIGN KEY
> `sample_derivedmodel__somemodel_id_31aa39d5_fk_sample_so`;
> ALTER TABLE `sample_somemodel` MODIFY `id` bigint AUTO_INCREMENT NOT
> NULL;
> ALTER TABLE `sample_derivedmodel_relation` MODIFY `somemodel_id` bigint
> NOT NULL;
> }}}
>

> The marked line fails with the following message:
>
> {{{
> Error Code: 3780. Referencing column 'derivedmodel_id' and referenced
> column 'basemodel_ptr_id' in foreign key constraint
> 'sample_derivedmodel__derivedmodel_id_9f9fbb1f_fk_sample_de' are
> incompatible.
>
> }}}
>
> And this FK constraint is the one in the sample_derivedmodel_relation, I
> suspect because the relation table is not modified to use bigints for the
> foreign ids.
>
> I observed this only when using MYSQL but not on SQLITE.
>
> I prepared a minimal reproducible example here:
> [https://github.com/Hafnernuss/MigrationFail]

New description:

 This is somewhat related to #32743 and #32742

 Consider the following example:
 A simple inheritance where the child model has a M2M relation to some
 other model:


 {{{
 class SomeModel(models.Model):
 some_field = models.IntegerField(default=5)


 class BaseModel(models.Model):
 some_other_base_field = models.IntegerField(default=5)

 class Meta:
 abstract = False

 class DerivedModel(BaseModel):
 relation = models.ManyToManyField(SomeModel, related_name='+')
 }}}


 I have altered migration 0001 manually to mimic the create behaviour prior
 to Django 3.2 (AutoField instead of BigAuto for PK)
 The second migration correctly picks up that this needs to be changed.

 The resulting sql query for 0002 is:

 {{{
 --
 -- Alter field id on basemodel
 --
 ALTER TABLE `sample_derivedmodel` DROP FOREIGN KEY
 `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk_sample_ba`;
 ALTER TABLE `sample_basemodel` MODIFY `id` bigint AUTO_INCREMENT NOT NULL;
 ALTER TABLE `sample_derivedmodel` MODIFY `basemodel_ptr_id` bigint NOT
 NULL; <- FAILS
 ALTER TABLE `sample_derivedmodel` ADD CONSTRAINT
 `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk` FOREIGN KEY
 (`basemodel_ptr_id`) REFERENCES `sample_basemodel` (`id`);
 --
 -- Alter field id on somemodel
 --
 ALTER TABLE `sample_derivedmodel_relation` DROP FOREIGN KEY
 `sample_derivedmodel__somemodel_id_31aa39d5_fk_sample_so`;
 ALTER TABLE `sample_somemodel` MODIFY `id` bigint AUTO_INCREMENT NOT NULL;
 ALTER TABLE `sample_derivedmodel_relation` MODIFY `somemodel_id` bigint
 NOT NULL;
 }}}


 The marked line fails with the following message:

 {{{
 Error Code: 3780. Referencing column 'derivedmodel_id' and referenced
 column 'basemodel_ptr_id' in foreign key constraint
 'sample_derivedmodel__derivedmodel_id_9f9fbb1f_fk_sample_de' are
 incompatible.

 }}}

 And this FK 

Re: [Django] #33314: Migration Fail with MTI and Many2Many relation when switching PK type

2021-11-23 Thread Django
#33314: Migration Fail with MTI and Many2Many relation when switching PK type
-+-
 Reporter:  Philipp  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, MTI, | Triage Stage:
  ManyToMany |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Philipp:

Old description:

> This is somewhat related to #32743 and #32742
>
> Consider the following example:
> A simple inheritance where the child model has a M2M relation to some
> other model:
>

> {{{
> class SomeModel(models.Model):
> some_field = models.IntegerField(default=5)
>

> class BaseModel(models.Model):
> some_other_base_field = models.IntegerField(default=5)
>
> class Meta:
> abstract = False
>
> class DerivedModel(BaseModel):
> relation = models.ManyToManyField(SomeModel, related_name='+')
> }}}
>

> I have altered migration 0001 manually to mimic the create behaviour
> prior to Django 3.2 (AutoField instead of BigAuto for PK)
> The second migration correctly picks up that this needs to be changed.
>
> The resulting sql query for 0002 is:
>
> {{{
> --
> -- Alter field id on basemodel
> --
> ALTER TABLE `sample_derivedmodel` DROP FOREIGN KEY
> `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk_sample_ba`;
> ALTER TABLE `sample_basemodel` MODIFY `id` bigint AUTO_INCREMENT NOT
> NULL;
> ALTER TABLE `sample_derivedmodel` MODIFY `basemodel_ptr_id` bigint NOT
> NULL; <- FAILS
> ALTER TABLE `sample_derivedmodel` ADD CONSTRAINT
> `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk` FOREIGN KEY
> (`basemodel_ptr_id`) REFERENCES `sample_basemodel` (`id`);
> --
> -- Alter field id on somemodel
> --
> ALTER TABLE `sample_derivedmodel_relation` DROP FOREIGN KEY
> `sample_derivedmodel__somemodel_id_31aa39d5_fk_sample_so`;
> ALTER TABLE `sample_somemodel` MODIFY `id` bigint AUTO_INCREMENT NOT
> NULL;
> ALTER TABLE `sample_derivedmodel_relation` MODIFY `somemodel_id` bigint
> NOT NULL;
> }}}
>

> The marked line fails with the following message:
> Error Code: 3780. Referencing column 'derivedmodel_id' and referenced
> column 'basemodel_ptr_id' in foreign key constraint
> 'sample_derivedmodel__derivedmodel_id_9f9fbb1f_fk_sample_de' are
> incompatible.
>
> And this FK constraint is the one in the sample_derivedmodel_relation, I
> suspect because the relation table is not modified to use bigints for the
> foreign ids.
>
> I observed this only when using MYSQL but not on SQLITE.
>
> I prepared a minimal reproducible example here:
> [https://github.com/Hafnernuss/MigrationFail]

New description:

 This is somewhat related to #32743 and #32742

 Consider the following example:
 A simple inheritance where the child model has a M2M relation to some
 other model:


 {{{
 class SomeModel(models.Model):
 some_field = models.IntegerField(default=5)


 class BaseModel(models.Model):
 some_other_base_field = models.IntegerField(default=5)

 class Meta:
 abstract = False

 class DerivedModel(BaseModel):
 relation = models.ManyToManyField(SomeModel, related_name='+')
 }}}


 I have altered migration 0001 manually to mimic the create behaviour prior
 to Django 3.2 (AutoField instead of BigAuto for PK)
 The second migration correctly picks up that this needs to be changed.

 The resulting sql query for 0002 is:

 {{{
 --
 -- Alter field id on basemodel
 --
 ALTER TABLE `sample_derivedmodel` DROP FOREIGN KEY
 `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk_sample_ba`;
 ALTER TABLE `sample_basemodel` MODIFY `id` bigint AUTO_INCREMENT NOT NULL;
 ALTER TABLE `sample_derivedmodel` MODIFY `basemodel_ptr_id` bigint NOT
 NULL; <- FAILS
 ALTER TABLE `sample_derivedmodel` ADD CONSTRAINT
 `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk` FOREIGN KEY
 (`basemodel_ptr_id`) REFERENCES `sample_basemodel` (`id`);
 --
 -- Alter field id on somemodel
 --
 ALTER TABLE `sample_derivedmodel_relation` DROP FOREIGN KEY
 `sample_derivedmodel__somemodel_id_31aa39d5_fk_sample_so`;
 ALTER TABLE `sample_somemodel` MODIFY `id` bigint AUTO_INCREMENT NOT NULL;
 ALTER TABLE `sample_derivedmodel_relation` MODIFY `somemodel_id` bigint
 NOT NULL;
 }}}


 The marked line fails with the following message:

 {{{
 Error Code: 3780. Referencing column 'derivedmodel_id' and referenced
 column 'basemodel_ptr_id' in foreign key constraint
 'sample_derivedmodel__derivedmodel_id_9f9fbb1f_fk_sample_de' are
 incompatible.

 }}}

 And this FK constraint is the 

[Django] #33314: Migration Fail with MTI and Many2Many relation when switching PK type

2021-11-23 Thread Django
#33314: Migration Fail with MTI and Many2Many relation when switching PK type
-+-
   Reporter:  Philipp|  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  3.2
  Migrations |   Keywords:  migrations, MTI,
   Severity:  Normal |  ManyToMany
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This is somewhat related to #32743 and #32742

 Consider the following example:
 A simple inheritance where the child model has a M2M relation to some
 other model:


 {{{
 class SomeModel(models.Model):
 some_field = models.IntegerField(default=5)


 class BaseModel(models.Model):
 some_other_base_field = models.IntegerField(default=5)

 class Meta:
 abstract = False

 class DerivedModel(BaseModel):
 relation = models.ManyToManyField(SomeModel, related_name='+')
 }}}


 I have altered migration 0001 manually to mimic the create behaviour prior
 to Django 3.2 (AutoField instead of BigAuto for PK)
 The second migration correctly picks up that this needs to be changed.

 The resulting sql query for 0002 is:

 {{{
 --
 -- Alter field id on basemodel
 --
 ALTER TABLE `sample_derivedmodel` DROP FOREIGN KEY
 `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk_sample_ba`;
 ALTER TABLE `sample_basemodel` MODIFY `id` bigint AUTO_INCREMENT NOT NULL;
 ALTER TABLE `sample_derivedmodel` MODIFY `basemodel_ptr_id` bigint NOT
 NULL; <- FAILS
 ALTER TABLE `sample_derivedmodel` ADD CONSTRAINT
 `sample_derivedmodel_basemodel_ptr_id_a3110b27_fk` FOREIGN KEY
 (`basemodel_ptr_id`) REFERENCES `sample_basemodel` (`id`);
 --
 -- Alter field id on somemodel
 --
 ALTER TABLE `sample_derivedmodel_relation` DROP FOREIGN KEY
 `sample_derivedmodel__somemodel_id_31aa39d5_fk_sample_so`;
 ALTER TABLE `sample_somemodel` MODIFY `id` bigint AUTO_INCREMENT NOT NULL;
 ALTER TABLE `sample_derivedmodel_relation` MODIFY `somemodel_id` bigint
 NOT NULL;
 }}}


 The marked line fails with the following message:
 Error Code: 3780. Referencing column 'derivedmodel_id' and referenced
 column 'basemodel_ptr_id' in foreign key constraint
 'sample_derivedmodel__derivedmodel_id_9f9fbb1f_fk_sample_de' are
 incompatible.

 And this FK constraint is the one in the sample_derivedmodel_relation, I
 suspect because the relation table is not modified to use bigints for the
 foreign ids.

 I observed this only when using MYSQL but not on SQLITE.

 I prepared a minimal reproducible example here:
 [https://github.com/Hafnernuss/MigrationFail]

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


Re: [Django] #33308: Add psycopg3 backend

2021-11-23 Thread Django
#33308: Add psycopg3 backend
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  backend orm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paolo Melchiorre):

 Hi Daniele

 Thank, I'll take a look at both branches and let you know.

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


Re: [Django] #33310: Remove unused "actions.selected" CSS class.

2021-11-23 Thread Django
#33310: Remove unused "actions.selected" CSS class.
-+-
 Reporter:  Álvaro Pelegrina |Owner:  Álvaro
  Fernández  |  Pelegrina Fernández
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  fixed
 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 GitHub ):

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


Comment:

 In [changeset:"98352ddf3a1ccffe8d38ecb34e1a51ed58d29cf3" 98352ddf]:
 {{{
 #!CommitTicketReference repository=""
 revision="98352ddf3a1ccffe8d38ecb34e1a51ed58d29cf3"
 Fixed #33310 -- Removed unused rule from admin CSS.

 Unused since 30e59705fc3e3e9e8370b965af794ad6173bf92b.
 }}}

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


Re: [Django] #33309: DISTINCT ON fails with mixed-case field aliases

2021-11-23 Thread Django
#33309: DISTINCT ON fails with mixed-case field aliases
-+-
 Reporter:  Christophe Thiery|Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"bdcda1ca9ba254743269e482384c2711ac34b1f1" bdcda1ca]:
 {{{
 #!CommitTicketReference repository=""
 revision="bdcda1ca9ba254743269e482384c2711ac34b1f1"
 Fixed #33309 -- Fixed QuerySet.distinct() crash on mixed case annotation.
 }}}

-- 
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/078.b5b008f996714139c56efec89f4936b4%40djangoproject.com.


[Django] #33313: Inheriting from multiple abstract models with same field causes name collision when overriding field is direct parent

2021-11-23 Thread Django
#33313: Inheriting from multiple abstract models with same field causes name
collision when overriding field is direct parent
-+-
   Reporter:  Ben Nace   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Given the following example models:

 {{{
 class ModelActivation(models.Model):
 start_date = models.DateField(null=True, blank=True)
 end_date = models.DateField(null=True, blank=True)
 active = models.BooleanField()

 class Meta:
 abstract = True

 class BaseData(ModelActivation):
 entity_state = models.CharField(max_length=100)

 class Meta:
 abstract = True

 class RequiredStart(models.Model):
 start_date = models.DateField()

 class Meta:
 abstract = True

 class RequiredEnd(models.Model):
 end_date = models.DateField()

 class Meta:
 abstract = True

 class RequiredStartEnd(RequiredStart, RequiredEnd):
 class Meta:
 abstract = True
 }}}
 \\

 Any of the following when the override for start_date is defined on a
 direct parent model, results in the error "(models.E006) The field
 'start_date' clashes with the field 'start_date' from model
 'app.testmodel' (or 'app.testmodel2')"
 {{{
 class TestModel(RequiredStart, BaseData):
 pass

 class TestModel2(RequiredStart, ModelActivation):
 pass
 }}}
 However, if the overriding field is pushed up to a grandparent model,
 rather than a direct parent, it works fine.
 {{{
 class TestModel3(RequiredStartEnd, BaseData):
 pass

 class TestModel4(RequiredStartEnd, ModelActivation):
 pass
 }}}

 In my limited debugging, it appears to me that this is because of the way
 inherited_attributes is tracked in the __new__ method of the ModelBase
 model metaclass (in django.db.models.base.py). For a grandparent model,
 not being a direct parent, all items in the __dict__ will be added to
 inherited_attributes, which includes the fields:

 {{{
 if base not in parents or not hasattr(base, '_meta'):
 # Things without _meta aren't functional models, so
 they're
 # uninteresting parents.
 inherited_attributes.update(base.__dict__)
 continue
 }}}

 However, when a field is inherited from a direct parent, it is not added
 to inherited_attributes, it is not added to field_names, and it does not
 appear in new_class.__dict__, so the field from the ancestor higher up in
 the mro is also added via

 {{{
 for field in parent_fields:
 if (field.name not in field_names and
 field.name not in new_class.__dict__ and
 field.name not in inherited_attributes):
 new_field = copy.deepcopy(field)
 new_class.add_to_class(field.name, new_field)
 }}}

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

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


Re: [Django] #33309: DISTINCT ON fails with mixed-case field aliases

2021-11-23 Thread Django
#33309: DISTINCT ON fails with mixed-case field aliases
-+-
 Reporter:  Christophe Thiery|Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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):

 * 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/078.5103090f81a27fab15ee91325a9ea721%40djangoproject.com.


Re: [Django] #33309: DISTINCT ON fails with mixed-case field aliases

2021-11-23 Thread Django
#33309: DISTINCT ON fails with mixed-case field aliases
-+-
 Reporter:  Christophe Thiery|Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Arsalan Ghassemi):

 New PR (changed target to main branch) :
 https://github.com/django/django/pull/15119

-- 
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/078.437d60f35ca98035b7400cd18810ebe9%40djangoproject.com.


[Django] #33312: Errors when trying to clone an object from a deferred queryset

2021-11-23 Thread Django
#33312: Errors when trying to clone an object from a deferred queryset
-+-
   Reporter:  Adam   |  Owner:  nobody
  Sołtysik   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 As per [https://docs.djangoproject.com/en/3.2/topics/db/queries/#copying-
 model-instances documentation], it's possible to clone objects by setting
 `pk = None`.

 However, if the object to clone comes from a deferred queryset (after
 calling `defer` or `only`), trying to save the copy raises some hard to
 decipher exceptions.

 {{{
 class DeferCloneTest(TestCase):
 @classmethod
 def setUpTestData(cls):
 SimpleItem.objects.create(name="test", value=42)

 def _get_item(self):
 item = SimpleItem.objects.defer('value').first()  # same with
 `only` instead of `defer`
 item.pk = None
 item._state.adding = True  # doesn't seem to change anything
 return item

 def test_save(self):
 self._get_item().save()  # ValueError: Cannot force an update in
 save() with no primary key.

 def test_save_force_insert(self):
 self._get_item().save(force_insert=True)  #
 SimpleItem.DoesNotExist

 def test_bulk_create(self):
 SimpleItem.objects.bulk_create([self._get_item()])  #
 SimpleItem.DoesNotExist
 }}}

 Possibly related: #27419, #28019.

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


Re: [Django] #33308: Add psycopg3 backend

2021-11-23 Thread Django
#33308: Add psycopg3 backend
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  backend orm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniele Varrazzo):

 Hello Paolo,

 I have rebased my Django branch on current main in a new
 [https://github.com/dvarrazzo/django/tree/psycopg3-4.1 psycopg3-4.1
 branch] and I have made the [https://github.com/dvarrazzo/django-
 psycopg3-backend django-psycopg3-backend] ''almost'' compatible with it:
 there are a few issues described [https://github.com/dvarrazzo/django-
 psycopg3-backend/commit/17cd24ae8eb49025b2a859c19a2a30081c2a028b in this
 commit message], together with how to run tests.

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


Re: [Django] #8576: Multiple AutoFields in a model

2021-11-23 Thread Django
#8576: Multiple AutoFields in a model
-+-
 Reporter:  honeyman |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  multiple autofield   | Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by logikonabstractions):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Know this is closed, but again just to provide perspective.

 I could really have used this feature actually. I have a project with
 existing data where they use as an ID an auto-increment (just like
 Django's default id). However, they also use a different no_header.
 Sometimes they create revision on their object, so basically their db ends
 up looking like this:

 id no_header suite
 1  1  0
 2  2  0
 3  1  1
 4  3  0
 ..

 So essentially, the no_header is an auto-increment, that only increments
 on the creation of new objects (with suite=0). If an object undergo some
 specific operation, then its no_header remains the same, but suite += 1.

 Which means that the no_header ends up running "behind" the id field, but
 it still needs to be an auto-increment. Of course I can override save() &
 do all that business there, but it would still be so much simpler to just
 have 2 auto-increment fields. IMO this is a conception flaw in the
 database backends - e.g there isn't an obvious reason to limit auto
 increment to a single field, if a separate attributes allows specifying
 what is a primary key. But I digress. Mostly wanted to illustrate a use
 case.

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


Re: [Django] #33309: DISTINCT ON fails with mixed-case field aliases

2021-11-23 Thread Django
#33309: DISTINCT ON fails with mixed-case field aliases
-+-
 Reporter:  Christophe Thiery|Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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 Arsalan Ghassemi):

 * 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/078.a7af8b7392ebd1772d6bc01da5f1f239%40djangoproject.com.


Re: [Django] #33309: DISTINCT ON fails with mixed-case field aliases

2021-11-23 Thread Django
#33309: DISTINCT ON fails with mixed-case field aliases
-+-
 Reporter:  Christophe Thiery|Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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 Arsalan Ghassemi):

 Sorry it's my first contribution to an open-source project and I forgot to
 mention the topic branch :
 https://github.com/ArsaCode/django/tree/ticket_33309

 I opened a PR with the changes :
 https://github.com/django/django/pull/15118

-- 
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/078.612610594730a7d6a8efaa2033420598%40djangoproject.com.


Re: [Django] #33309: DISTINCT ON fails with mixed-case field aliases

2021-11-23 Thread Django
#33309: DISTINCT ON fails with mixed-case field aliases
-+-
 Reporter:  Christophe Thiery|Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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 Arsalan Ghassemi):

 I was able to reproduce the bug in my environment and added the regression
 test.

 I'm currently working on the fix and will open a PR soon.

-- 
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/078.1392e56d45fba55d1789a7e00c3ca5a2%40djangoproject.com.


Re: [Django] #33310: Remove unused "actions.selected" CSS class.

2021-11-23 Thread Django
#33310: Remove unused "actions.selected" CSS class.
-+-
 Reporter:  Álvaro Pelegrina |Owner:  Álvaro
  Fernández  |  Pelegrina Fernández
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 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 Álvaro Pelegrina Fernández):

 Great, I patches those css files.

 This is it's related PR https://github.com/django/django/pull/15117

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


Re: [Django] #33310: Remove unused "actions.selected" CSS class.

2021-11-23 Thread Django
#33310: Remove unused "actions.selected" CSS class.
-+-
 Reporter:  Álvaro Pelegrina |Owner:  Álvaro
  Fernández  |  Pelegrina Fernández
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 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 Álvaro Pelegrina Fernández):

 * 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/067.243b2525a113af38f023cec3be214921%40djangoproject.com.


Re: [Django] #33310: Remove unused "actions.selected" CSS class.

2021-11-23 Thread Django
#33310: Remove unused "actions.selected" CSS class.
-+-
 Reporter:  Álvaro Pelegrina |Owner:  Álvaro
  Fernández  |  Pelegrina Fernández
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 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 Álvaro Pelegrina Fernández):

 * owner:  nobody => Álvaro Pelegrina Fernández
 * 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/067.d0e98f812d718f5ffdde2b3606b9c7e8%40djangoproject.com.


[Django] #33311: Disallow overriding parent blocks within conditionals.

2021-11-23 Thread Django
#33311: Disallow overriding parent blocks within conditionals.
-+-
   Reporter:  Nat S  |  Owner:  nobody
  Dunn   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Template   |Version:  3.2
  system |   Keywords:  block, conditional,
   Severity:  Normal |  if
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When a parent block is overridden in an if condition, the overridden
 content is output regardless of the truthiness of the condition.  For
 example:

 {{{
 {% if False %}
   {% block parent %}Foo{% endblock parent %}
 {% endif %}
 }}}



 Foo gets output, which feels wrong. Either this structure should be
 disallowed or the behavior should change.

 If Django disallows overriding parent blocks within conditionals, then it
 would be great if the error message could include a hint describing the
 following workaround:

 {{{
 {% block parent %}
   {% if False %}
 {% block parent %}Foo{% endblock parent %}
   {% else %}
 {{ block.super }}
   {% endif %}
 {% endblock parent %}
 }}}

-- 
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/051.8354b62c4e04774f0b4277ad570c04d5%40djangoproject.com.


Re: [Django] #33310: Remove unused "actions.selected" CSS class.

2021-11-23 Thread Django
#33310: Remove unused "actions.selected" CSS class.
--+
 Reporter:  alvaromlg |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  3.2
 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 Mariusz Felisiak):

 The same can be removed from `responsive.css`.

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


Re: [Django] #4282: startproject should honor umask

2021-11-23 Thread Django
#4282: startproject should honor umask
-+-
 Reporter:  talex5+django@…  |Owner:  Ad
 |  Timmering
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 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 Ad Timmering):

 * needs_better_patch:  1 => 0


Comment:

 Thanks for the review Mariusz, learning from your comments. Applied the
 changes.

-- 
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/081.30622cd613a4fe0e27ef914e337e8ea6%40djangoproject.com.


Re: [Django] #33310: Remove unused "actions.selected" CSS class. (was: Django admin Select All CSS seems inconsistent on latest 3.2.9 version)

2021-11-23 Thread Django
#33310: Remove unused "actions.selected" CSS class.
--+
 Reporter:  alvaromlg |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  3.2
 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):

 * cc: Carlton Gibson (added)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report, we
 [https://github.com/django/django/pull/14870#issuecomment-923712827
 noticed] this change when fixing #33083. I think now it looks better,
 feel-free to removed unused CSS class.

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


[Django] #33310: Django admin Select All CSS seems inconsistent on latest 3.2.9 version

2021-11-23 Thread Django
#33310: Django admin Select All CSS seems inconsistent on latest 3.2.9 version
+
   Reporter:  alvaromlg |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |Version:  3.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:  0 |
+
 Hello,

 First of all I am not sure if this is intended, it's a change happening on
 Django 3.2

 On Django 3.1 this was the admin styling on Select All

 [[Image(https://i.imgur.com/hvIRkis.png)]]

 And on Django 3.2 it looks like this:

 [[Image(https://i.imgur.com/DyiY43M.png)]]

 Is it intended? Javascript doesnt add anymore the "selected" class and
 even if you add it manually it doesnt apply the yellow color because the
 CSS class just apply the body background color.

 If it's intended I think we can refactor and just remove this CSS code at
 changelist.css (and maybe in other places) because it's indeed (as the
 comment says) not used and its a bit confusing when overriding it for
 django admin template overriding purposes.

 
https://github.com/django/django/blob/main/django/contrib/admin/static/admin/css/changelists.css#L299

-- 
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/052.241623093ac8167060ca7c5e5d2fd992%40djangoproject.com.


Re: [Django] #22617: Allow to fix translation -> Fix makemessages to not delete debug data and hide errors (and all similar modules using "msgmerge")

2021-11-23 Thread Django
#22617: Allow to fix translation -> Fix makemessages to not delete debug data 
and
hide errors (and all similar modules using "msgmerge")
-+-
 Reporter:  Cezary.Wagner|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  dev
  commands)  |
 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):

 * cc: Ad Timmering (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/071.55a6c203737df3d2ac29dbe4ccf436a9%40djangoproject.com.


Re: [Django] #22977: No validation error when ForeignKey related_name clashes with manager name.

2021-11-23 Thread Django
#22977: No validation error when ForeignKey related_name clashes with manager 
name.
--+
 Reporter:  Russell Keith-Magee   |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (System checks)  |  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):

 * owner:  Davide Ceretti => (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/066.32f79ea606ecf7bf009f770c3b28dc24%40djangoproject.com.


Re: [Django] #9249: Google Analytics' Cookies break CacheMiddleware when SessionMiddleware turns on Vary: Cookie

2021-11-23 Thread Django
#9249: Google Analytics' Cookies break CacheMiddleware when SessionMiddleware
turns on Vary: Cookie
---+
 Reporter:  pixelcort  |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.0
 Severity:  Normal |   Resolution:
 Keywords:  cache cookies  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * owner:  Łukasz Langa => (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/067.d69228f1cd516847625bd4997c1bdcf0%40djangoproject.com.


Re: [Django] #5899: Allow admin fieldsets to be collapsible but not initially collapsed

2021-11-23 Thread Django
#5899: Allow admin fieldsets to be collapsible but not initially collapsed
-+-
 Reporter:  Ionut Ciocirlan  |Owner:  (none)
  |
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  newforms-
 |  admin
 Severity:  Normal   |   Resolution:
 Keywords:  admin fieldset   | Triage Stage:  Accepted
  collapsed collapsible nfa-someday  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * owner:  Alexander Herrmann => (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/101.d4aebd278400fa5e1c55d495396be687%40djangoproject.com.


Re: [Django] #28358: LazyObject defines attribute that don't exist on wrapped object

2021-11-23 Thread Django
#28358: LazyObject defines attribute that don't exist on wrapped object
-+
 Reporter:  Andrey Fedoseev  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.11
 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 Sergey Fedoseev):

 * cc: Sergey Fedoseev (removed)


-- 
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/072.9d4285e4485f57dcc2a462296c44e941%40djangoproject.com.


Re: [Django] #28358: LazyObject defines attribute that don't exist on wrapped object

2021-11-23 Thread Django
#28358: LazyObject defines attribute that don't exist on wrapped object
-+
 Reporter:  Andrey Fedoseev  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.11
 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):

 * owner:  Sergey Fedoseev => (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/072.81404947ba2718ca78ca44e6830d36fc%40djangoproject.com.


Re: [Django] #22569: lookup_allowed fails to consider dynamic list_filter

2021-11-23 Thread Django
#22569: lookup_allowed fails to consider dynamic list_filter
-+-
 Reporter:  Keryn Knight |Owner:  (none)
   |
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  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):

 * owner:  Simon Meers => (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/095.f86f6663b034a9ce0b8cced37779de5c%40djangoproject.com.


Re: [Django] #33213: Document coverage setup for parallel tests

2021-11-23 Thread Django
#33213: Document coverage setup for parallel tests
---+
 Reporter:  Mr. Glass  |Owner:  Martin Pauly
 Type:  New feature|   Status:  assigned
Component:  Documentation  |  Version:
 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 Martin Pauly):

 * has_patch:  0 => 1


Comment:

 Pull Request: [https://github.com/django/django/pull/15116]

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


Re: [Django] #33309: DISTINCT ON fails with mixed-case field aliases

2021-11-23 Thread Django
#33309: DISTINCT ON fails with mixed-case field aliases
-+-
 Reporter:  Christophe Thiery|Owner:  Arsalan
 |  Ghassemi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Egor R):

 * cc: Egor R (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/078.4d33e00c3c7e36fa12c93b3aeeef26ab%40djangoproject.com.


Re: [Django] #33304: Window(order_by) should allow usage of descending string syntax to be used

2021-11-23 Thread Django
#33304: Window(order_by) should allow usage of descending string syntax to be 
used
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 |  Charette
 Type:  New feature  |   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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"aec71aaa5b029640ce066fe5dc34f7a0050d50b2" aec71aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="aec71aaa5b029640ce066fe5dc34f7a0050d50b2"
 Fixed #33304 -- Allowed passing string expressions to Window(order_by).
 }}}

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


Re: [Django] #33304: Window(order_by) should allow usage of descending string syntax to be used

2021-11-23 Thread Django
#33304: Window(order_by) should allow usage of descending string syntax to be 
used
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 |  Charette
 Type:  New feature  |   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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e06dc4571ea9fd5723c8029959b95808be9f8812" e06dc457]:
 {{{
 #!CommitTicketReference repository=""
 revision="e06dc4571ea9fd5723c8029959b95808be9f8812"
 Refs #33304 -- Enclosed aggregate ordering logic in an expression.

 This greatly simplifies the implementation of contrib.postgres'
 OrderableAggMixin and allows for reuse in Window expressions.
 }}}

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