Is your feature request related to a problem? Please describe.
When an organization is disabled (is_active = False), writes against objects related to that organization are not consistently blocked.
Some paths already behave correctly through membership filtering, but that is not a reliable or explicit protection. A few write paths still bypass it, and disabled organizations can also appear in organization selection widgets.
Describe the solution you'd like
Make disabled organizations a first-class write guard.
Objects related to a disabled organization should:
- remain readable
- remain deletable
- be blocked from creation
- be blocked from update
In addition, organization selection fields, autocomplete widgets, and other FK pickers should exclude disabled organizations.
This behavior should be enforced consistently across:
- Django admin
- DRF views and permissions
- model validation for membership and ownership records
- queryset helpers used by organization selectors and autocomplete fields
Goals
- make the disabled-organization rule explicit instead of relying on indirect membership filtering
- provide reusable admin and DRF mixins that downstream apps can adopt
- provide a shared helper/queryset pattern for active organizations and memberships
- ensure the rule applies uniformly, including for superusers unless a view explicitly opts out
- keep read and delete operations available so disabled-organization data can still be audited and cleaned up
- keep organization lifecycle operations working, including re-enabling a disabled organization
- surface clear, translatable error messages instead of silent failures or empty querysets
Deliverables
- reusable Django admin and DRF mixins for guarding writes on disabled-organization objects
- model-level validation for membership and ownership records
- updates to organization FK/autocomplete querysets so disabled organizations are excluded from selection
- migration of existing openwisp-users call sites to the new mixins/helpers
- clear error messages when a write is blocked
Notes
- This issue is about write protection, not authentication or organization lifecycle changes.
- Existing logic that intentionally shows disabled organizations for auditing or lifecycle management should remain available where needed.
- The change should be implemented in a way that downstream OpenWISP apps can reuse.
Reference: OpenWISP Device Operation Analysis
Is your feature request related to a problem? Please describe.
When an organization is disabled (
is_active = False), writes against objects related to that organization are not consistently blocked.Some paths already behave correctly through membership filtering, but that is not a reliable or explicit protection. A few write paths still bypass it, and disabled organizations can also appear in organization selection widgets.
Describe the solution you'd like
Make disabled organizations a first-class write guard.
Objects related to a disabled organization should:
In addition, organization selection fields, autocomplete widgets, and other FK pickers should exclude disabled organizations.
This behavior should be enforced consistently across:
Goals
Deliverables
Notes
Reference: OpenWISP Device Operation Analysis