django-polymorphic
django-polymorphic copied to clipboard
Improved Django model inheritance with automatic downcasting
updates: - [github.com/astral-sh/ruff-pre-commit: v0.4.8 → v0.5.0](https://github.com/astral-sh/ruff-pre-commit/compare/v0.4.8...v0.5.0)
Inheriting from PolymorphicParentModelAdmin class break the django admin "preserve filter" behavior. Removing the "get_preserved_filters" in polymorphic/admin/parentadmin.py solves the problem. Why is this override needed?
I have the following mdels: ``` class PolyDevice(Model): name = CharField(max_length=64) class NotPolyInterface(PolymorphicModel): name = CharField(max_length=64) device = ForeignKey(to=PolyDevice, on_delete=CASCADE) ethernety_stuff = CharField(max_length=64) modular_stuff = CharField(max_length=64) fixed_stuff = CharField(max_length=64) wirelessy_stuff...
updates: - [github.com/pre-commit/pre-commit-hooks: v4.6.0 → v5.0.0](https://github.com/pre-commit/pre-commit-hooks/compare/v4.6.0...v5.0.0) - [github.com/astral-sh/ruff-pre-commit: v0.4.8 → v0.7.0](https://github.com/astral-sh/ruff-pre-commit/compare/v0.4.8...v0.7.0)
It seems the project is depending _**implicitly**_ on setuptools at runtime. Systematic presence of setuptools should not be assumed; especially now since uv is eating pypa's lunch. Could that dependency...
Bumps [django](https://github.com/django/django) from 3.2.25 to 4.2.16. Commits 6f9fea3 [4.2.x] Bumped version for 4.2.16 release. bf4888d [4.2.x] Fixed CVE-2024-45231 -- Avoided server error on password reset when e... d147a8e [4.2.x] Fixed...
After updating to Django 5.1.1, I ran into errors using Aggregations: ```py File "/home/me/PycharmProjects/my-project/src/accounting/models.py", line 1440, in period return tuple(self.aggregate(Min("period_start"), Max("period_end")).values()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/me/PycharmProjects/my-project/.venv/lib/python3.12/site-packages/polymorphic/query.py", line 316, in aggregate self._process_aggregate_args(args, kwargs)...
#### Description Hi, I've recently been onboarding to the Python.org repository and have upgraded the service from Django 2 to Django 4.2 - as such I'm relatively green to some...
When the `real_object` has a different class from `real_class`, it gets transmogrified into `real_class`. When it implements `__init__,` it is not called. https://github.com/jazzband/django-polymorphic/pull/614
…bject. The __init__ wasn't called previously. https://github.com/jazzband/django-polymorphic/issues/615