3👍
I suspect that adding a new field isn’t the cause of the problem – it’s just coincidence that the problem arose at the same time as you made this change. The clue is in the traceback:
File "/usr/local/lib/python3.9/site-packages/django/contrib/contenttypes/fields.py", line 243, in __get__
rel_obj = ct.get_object_for_this_type(pk=pk_val)
File "/usr/local/lib/python3.9/site-packages/django/contrib/contenttypes/models.py", line 175, in get_object_for_this_type
return self.model_class()._base_manager.using(self._state.db).get(**kwargs)
AttributeError: 'NoneType' object has no attribute '_base_manager'
Specifically, the error is coming from the contenttypes framework – i.e., your content_type field is broken on at least one existing model instance in the database. The model_class() method is returning a null value instead of the model class.
The most likely cause of this is that you have deleted a model which was previously being referred to by your generic foreign key, or you have removed the app which provided that model from INSTALLED_APPS.
You should be able to resolve the issue by running the remove_stale_contenttypes management command. If that doesn’t work, then it’s probably going to be a case of manually inspecting the database to find out where the problem is (emptying the whole database will also help verify whether this is the issue).
The FieldDoesNotExist exception is not a problem. It would be properly handled by Django if there wasn’t an issue with your content types.
Side note: I don’t think it has anything to do with your problem, but it’s not a good idea to use names that clash with Python built-in functions as it can lead to confusing behaviour.