Skip to content

serviceability: add DeviceProvisioning and LinkProvisioning to device.status #2297

@juan-malbeclabs

Description

@juan-malbeclabs

NOTE: The details below may be outdated, please check rfcs/rfc2-network-provisioning.md

Context / Why

We need to expand the standard status field of the Device account to explicitly track its provisioning and activation lifecycle. This provides clearer separation of contributor vs. foundation actions and ensures a consistent onboarding, review, and activation workflow. It also introduces an explicit Outage state for contributor-driven maintenance.

What to do

  • Add new lifecycle states to the existing status field.
  • Define the following transition flow:

Diagram

Provisioning ──(contributor)──> ReadyForService ──(foundation)──> Activated ──(contributor)──> Outage
Outage ──(contributor)──> Activated
Outage ──(contributor)──> Provisioning

Access Control Rules

  • Contributor can:

    • Provisioning → ReadyForService
    • Activated → Outage
    • Outage → Activated
    • Outage → Provisioning
  • Foundation can:

    • ReadyForService → Activated

CLI Updates

  • Allow contributors to set the device’s lifecycle status via CLI.
  • Display the current status (including new lifecycle states) in dz device list and detail views.

How (High-Level)

  • Extend the existing status enum of the Device account to include provisioning lifecycle states.
  • Enforce valid state transitions directly within on-chain logic.
  • Add authorization checks ensuring only valid actors can perform each transition.
  • Update CLI commands to support setting and displaying the new states.

Notes

  • Ensure backward compatibility by defaulting existing Devices to Activated.
  • Add regression tests covering allowed and invalid transitions.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions