[feature] Allow preventing changes to the organization of specific models

⚠️ not suited to first time contributors (PRs will be closed without explanation!).

Is your feature request related to a problem? Please describe.

OpenWISP uses the organization field on many models, but it does not have a shared rule for whether that field can be changed after an object has been created.

Some objects must stay in their original organization. Changing the organization of a VPN server, certificate authority, certificate, VPN-client template, or certificate-generator template can leave credentials, configuration, or related records connected to the wrong organization.

This has led to related Controller work in #1050, #1334, and #1459. While reviewing certificate-template work in #1378, we found more cases that need the same kind of protection.

Adding a separate check every time a new case is discovered will create different behavior in different applications and will eventually miss important cases. We need one reusable rule that every OpenWISP module can use.

Describe the solution you'd like

Add this class attribute to OrgMixin and ShareableOrgMixin:

organization_change_allowed = True

A model that must not change organization after creation sets:

organization_change_allowed = False

When an object is loaded from the database, OrgMixin.from_db() stores its original organization ID in _initial_organization_id. OrgMixin.refresh_from_db() updates this snapshot when the organization field is refreshed.

In OrgMixin.clean():

• If organization_change_allowed is False and the object already exists, compare _initial_organization_id with the current organization_id.
• Raise ValidationError if they differ.
• Treat changes between a specific organization and the shared organization (organization=None) as organization changes.
• Call super().clean() so model-specific validation continues to run.
• Support deferred fields and custom models which replace OpenWISP default models.
• Do not add database queries.

Django admin

For an existing object with organization_change_allowed = False, show the organization field as read-only on the Django admin change page.

The model validation remains the final protection, because admin UI restrictions can be bypassed.

REST API

REST API updates must reject organization changes with the model validation error.

Swagger documentation should make this rule visible:

• Creation requests show organization as writable.
• Update requests show organization as read-only when the model sets organization_change_allowed = False.

If the current schema generator cannot describe different create and update request fields, document the field clearly as: “Can be set when creating the resource. Cannot be changed afterwards.”

After adding the reusable mechanism, audit OpenWISP applications and set organization_change_allowed = False on models which must remain in their original organization.

The initial Controller audit should include:

• VPN servers
• Certificate authorities
• Certificates
• VPN-client templates
• Certificate-generator templates
• Other models discovered during the audit

Describe alternatives you've considered

Adding separate checks in each application can fix individual cases, but it duplicates logic and leads to inconsistent behavior.

Blocking organization changes for every model is too broad.

Database triggers would not work consistently with custom models and downstream OpenWISP applications.

Additional context

Related issues:

• https://github.com/openwisp/openwisp-users/issues/559
• https://github.com/openwisp/openwisp-controller/issues/1050
• https://github.com/openwisp/openwisp-controller/issues/1334
• https://github.com/openwisp/openwisp-controller/issues/1459
• https://github.com/openwisp/openwisp-controller/pull/1378

Start with OrgMixin and ShareableOrgMixin, especially from_db(), refresh_from_db(), and clean(), then inspect the Django admin and REST API/Swagger entry points described in the issue. Review the related Controller cases and model audit requirements. Done means reusable validation, admin and API enforcement, schema visibility, and identified models configured without database queries.