⚠️ 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:
Is your feature request related to a problem? Please describe.
OpenWISP uses the
organizationfield 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
OrgMixinandShareableOrgMixin:A model that must not change organization after creation sets:
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():organization_change_allowedisFalseand the object already exists, compare_initial_organization_idwith the currentorganization_id.ValidationErrorif they differ.organization=None) as organization changes.super().clean()so model-specific validation continues to run.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:
organizationas writable.organizationas read-only when the model setsorganization_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 = Falseon models which must remain in their original organization.The initial Controller audit should include:
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: