[change] Respect disabled organizations and deactivated devices in topology operations

[pandafy]

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

The OpenWISP Device Operation Analysis spreadsheet shows that openwisp-network-topology does not consistently enforce disabled-organization and deactivated-device policies.

For disabled organizations, topology data should remain readable and deletable, but new writes should be blocked. Today, several write paths can still create or modify topology data for organizations whose is_active flag is False.

For deactivated devices, device-driven topology operations should not recreate relations, update Device.management_ip, or trigger monitoring checks. Today, link and node updates can still fan out into device integration code without checking Device.is_deactivated().

Blockers

• [change] Make disabled organizations readonly but deletable openwisp-users#522
• [change] Generic enforcement of deactivated devices openwisp-controller#1338

Describe the solution you'd like

flowchart TD

    A["Topology Operation"]

    A --> B{"Policy Subject"}

    B --> C["Disabled Organization<br/>is_active = False"]
    B --> D["Deactivated Device<br/>Device.is_deactivated()"]

    C --> E{"Operation Type"}

    E --> F["Create / Update"]
    E --> G["Receive / Ingest"]
    E --> H["Async Diff / Fetch / Sync"]
    E --> I["Publish / Snapshot / WiFi Mesh"]
    E --> J["Read / Delete / Cleanup"]

    F --> F1["BLOCK"]
    G --> G1["BLOCK"]
    H --> H1["SKIP or ABORT"]
    I --> I1["BLOCK or explicitly skip"]
    J --> J1["ALLOW"]

    D --> K{"Device Integration Path"}

    K --> L["DeviceNode.auto_create"]
    K --> M["Link status changes"]
    K --> N["Monitoring check triggers"]
    K --> O["WiFi mesh from monitoring data"]

    L --> L1["Do not bind nodes<br/>to deactivated devices"]
    M --> M1["Do not update<br/>Device.management_ip"]
    N --> N1["Do not schedule<br/>monitoring checks"]
    O --> O1["Do not generate<br/>topology from deactivated data"]

    C --> P["Re-enabled Organization"]
    P --> P1["Normal topology operations resume"]

    A --> Q["Entry Points"]

    Q --> Q1["Admin / REST API"]
    Q --> Q2["Celery tasks"]
    Q --> Q3["Management commands"]
    Q --> Q4["Key-auth RECEIVE"]
    Q --> Q5["Scheduled jobs"]
    Q --> Q6["Signal handlers"]

Loading

Enforce disabled-organization rules consistently across topology write paths:

• block topology, node, and link create/update operations for disabled organizations;
• block key-auth RECEIVE ingestion for disabled-organization topologies;
• block async topology diff application when the organization is disabled;
• skip disabled organizations in scheduled fetch updates and management-command workflows;
• prevent publishing disabled-organization topologies if publishing would re-enable processing;
• skip or explicitly decide snapshot generation for disabled organizations;
• block WiFi mesh topology generation for disabled organizations;
• block DeviceNode writes for devices belonging to disabled organizations.

Enforce deactivated-device rules consistently in device integration paths:

• avoid binding nodes to deactivated devices in DeviceNode.auto_create();
• avoid updating Device.management_ip for deactivated devices on link status changes;
• avoid triggering monitoring checks for deactivated devices;
• avoid WiFi mesh topology generation from deactivated-device monitoring data.

Read-only operations should keep working unless a separate visibility policy says otherwise:

• graph generation;
• topology visualization;
• topology history retrieval;
• websocket broadcasts for already authorized subscribers.

Delete and cleanup operations should continue to be allowed, including expired node/link cleanup.

When an organization is re-enabled, topology operations should resume normally.

Describe alternatives you've considered

Only enforcing this in REST API and admin entry points would be incomplete because several important paths bypass those layers:

• Celery tasks such as topology diff application;
• key-auth topology ingestion;
• scheduled updates and management commands;
• signal-driven device integration;
• WiFi mesh generation.

The guards should therefore be implemented in the task/model/service layer where possible, with API and admin validation added where needed for clear user feedback.

Additional context

High-priority paths from the decision matrix include:

• topology.receive.ingest: validates only content type and topology key, then calls Topology.receive() without checking organization.is_active.
• topology.update.apply: loads Topology by primary key in Celery and applies diffs without revalidating organization or device state.
• topology.update.fetch: update_all() filters by published=True and strategy='fetch', but not by active organization.
• topology.crud.manage: non-superusers are mostly filtered, but superusers can still create or update disabled-organization topologies.
• topology.publish: publishing a disabled-organization topology may re-enable its processing pipeline.
• topology.snapshot.create: scheduled snapshots may keep accumulating for disabled organizations.
• topology.wifi_mesh.create: processes organization_ids directly and funnels generated data through receive() without active-organization or deactivated-device checks.
• controller.device.resolve: DeviceNode.auto_create() does not check organization__is_active or Device.is_deactivated().
• controller.device.update_management_ip: OpenVPN link-up can repopulate Device.management_ip after controller deactivation cleared it.
• controller.monitoring.trigger_checks: link changes can schedule monitoring checks for disabled-organization or deactivated devices.

Acceptance criteria:

• Create operations are blocked for objects belonging to disabled organizations.
• Update operations are blocked for objects belonging to disabled organizations.
• Read operations continue to work according to the agreed visibility policy.
• Delete and cleanup operations continue to work.
• Device-driven topology operations are blocked for deactivated devices.
• The restriction applies across admin, REST API, background tasks, management commands, ingestion endpoints, and device integration workflows.
• Re-enabling an organization restores normal behavior.
• Automated tests cover the affected write paths and async race windows.

[nemesifier]

Cross-reference for the disabled-organization follow-up set:

• [change] Make disabled organizations readonly but deletable openwisp-users#522
• [change] Limit controller operations on disabled organizations openwisp-controller#1393
• [change] Do not generate notifications for disabled organizations openwisp-notifications#472
• [change] Enforce disabled-organization rules in firmware upgrades openwisp-firmware-upgrader#445
• [change] Enforce disabled-organization rules in monitoring openwisp-monitoring#812
• [change] Enforce disabled-organization rules in RADIUS openwisp-radius#729

Compared with the Network-Topology | Decision Matrix sheet, this issue covers the overall disabled-organization and deactivated-device scope. The issue body should keep the following high-priority implementation details visible:

• controller.device.update_management_ip is the highest-severity deactivated-device path because link-up can repopulate Device.management_ip after controller deactivation cleared it.
• controller.device.resolve should filter out deactivated devices and inactive organizations before creating DeviceNode relations.
• topology.update.apply must re-check organization and device state in the Celery task, not only in views or admin.
• topology.receive.ingest should reject disabled-organization topologies because key authentication bypasses managed-organization filtering.
• topology.wifi_mesh.create should filter inactive organizations and deactivated devices from DeviceData before generating topology data.
• controller.monitoring.trigger_checks should not enqueue monitoring checks for deactivated or disabled-organization devices.
• Snapshot generation and publish/unpublish behavior need a policy decision for disabled organizations.