refactor: extract base model from member service

[braaar]

Here I am trying to extract the most general fields of a service, stripping away anything that is lab-specific or assumes a certain kind of way of doing things.

see #531 for the reasoning behind this.

I have come across a problem with this approach:

It is impossible to add a non-nullable field 'baseservice_ptr' to memberservice without specifying a default. This is because the database needs something to populate existing rows.
Please select a fix:
 1) Provide a one-off default now (will be set on all existing rows with a null value for this column)
 2) Quit and manually define a default value in models.py.

It seems we can't retroactively tell Django that a model wants to become a child of another model due to a (presumably) required foreign to the other model.

[braaar]

We might need to some som manual migration trickery like in this stackoverflow thread (expect we want to do the opposite)

[drjaska]

Code changes look good assuming that the new extra fields are meaningless but this likely needs database migrations? @tswfi

[vranki]

LGTM. Good idea.

[tswfi]

Code changes look good assuming that the new extra fields are meaningless but this likely needs database migrations? @tswfi

yup, this will probably require a manual migration file to be written. Django is usually pretty good at generating the migrations automatically but that seems to not be the case here..

Also we might want consider using a global base model that always adds things like CreationDateTime LastUpdateDateTime and so on for all models that we have.

The base model should also be marked as Abstract https://docs.djangoproject.com/en/5.1/topics/db/models/#abstract-base-classes as it should probably never be used directly.

[tswfi]

I converted this to draft so it is not merged before at least the migration is ok

[braaar]

@tswfi's suggestion about making the class abstract solved the migration problem! I ended up removing the service_id field since it is probably superfluous given that there already is an ID field under the hood (in the base model, I reckon). Having a special unique identifier on top of that feels too use case specific to include in the base model.