﻿id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
35729	Subclasses cannot opt out of natural key serialization	Jonas Dittrich	rimchoi	"We want to have a custom UserProfile that inherits from AbstractBaseUser without the need to define a natural key. There should be a nice way to do this.

Our custom UserProfile inherits from AbstractBaseUser. We don't have any possible unique field combination that we could use as a `natural_key`. (Our `USERNAME_FIELD` is not unique. It's an email that might be NULL for multiple users)

When dumping data, we want to use `natural_foreign=True` and `natural_primary=True` matching the 
documentation recommendations, see https://docs.djangoproject.com/en/5.1/topics/serialization/#natural-keys.

Now, `AbstractBaseUser` defines the `natural_key` function to return the value of `USERNAME_FIELD` and there doesn't seem to be an alternative implementation in our derived class.

Is there a way to dump our data using `natural_foreign=True` and `natural_primary=True` without serializing the user profile with natural keys?

What we tried so far:
- making natural_key just return `(pk,)`. This does not work. The pk of the user profile is not serialized because the model defines `natural_key` and django excludes the pk from the list of dumped fields when a `natural_key` exists, see https://github.com/django/django/blob/c6a4f853c7167c1001761dcff30d7a64690e8236/django/core/serializers/python.py#L37.
- overwriting `__getattribute__` on the user profile, raising an `AttributeError` when `natural_key` is requested. M2M fields call `hasattr` on the class, not on the instance which has the modified `__getattribute__` function.
- trying to delete the `natural_key` function from our user profile class using `del` and `delattr`. `hasattr` finds the function from the superclass; our user profile does not define the `natural_key` function.

Basically the problem is that removing the `natural_key` function from the child class violates Liskov's substitution principle.

In theory, we could `del AbstractBaseUser.natural_key` but this deeply interferes with Django; we don't want to do that."	Bug	closed	Core (Serialization)	dev	Normal	fixed			Ready for checkin	1	0	0	0	0	0
