[feature] Allow performing config changes in draft mode, changes can be confirmed & applied or rejected & discarded

[nemesifier]

⚠️ Not suited for beginners. Follow up of #1128.

In the current implementation, OpenWISP immediately applies every configuration change, even if the user is still editing related templates.

This prevents batching logically related changes, and can result in deploying incomplete configurations which can be potentially broken.

We need to redesign the configuration change mechanism to introduce a staging and apply model similar to OpenWrt’s “Save & Apply” concept.

Key Goals

• Prevent multiple SSH push operations when several configuration objects or templates are updated in sequence.
• Allow users to make and review several related changes before deployment.
• Ensure that when configurations are applied, the system performs exactly one consolidated deployment per device.
• Allow to discard changes, discarding must allow reverting every detail to the previous version of the object.

Functional Proposal

1. Draft Mode

   • Each configuration or template change is saved as a draft by default.
   • Draft changes do not trigger the config_modified signal or any SSH connection.
   • The UI shall indicate which configurations have un-applied drafts.

2. Apply Changes

   • A dedicated “Apply” action triggers a single deployment for all pending drafts related to a device.
   • This action sends one config_modified signal, ensuring only one SSH connection.

3. Discard Drafts

   • Users can discard pending drafts to revert to the last applied configuration.

4. Change Tracking

   • Track which configuration objects or templates have pending drafts.

5. Concurrency Handling

   • If a deployment is ongoing, further “Apply” actions should be queued or disabled until completion.

Constraints

• Ensure feature parity between Admin and REST API
• Allow saving and applying changes right away (current behavior)
• Ensure only 1 config_modified signal is sent for each device, regardless of the amount of objects changed
• Any object which can impact the configuration checksum of a device needs to be part of this design, eg:
  • devices
  • configs
  • templates
  • device groups
  • organizations
  • I hope I am not forgetting anything!
    • Maybe VPN servers too?
    • What about subnets and IP addresses?

Benefits

• Eliminates redundant SSH connections.
• Prevents partial deployments when multiple dependent objects are being changed (eg: configuration variables, group variables, group templates, templates, etc).
• Improves user experience by aligning with OpenWrt’s familiar configuration workflow.

Next Steps

• Prototype UI changes for “Save Draft”, “Apply”, and “Discard” actions.
• Outline code changes required to support the goals stated in this issue.
• Discuss backward compatibility and migration strategy for existing configurations.

[Piyushrathoree]

@nemesifier I'm ready for this . can you assign ?

[nemesifier]

@Piyushrathoree ⚠️ Not suited for beginners.

It's written on top. This issue is not listed in the contributor's board. Please refer to "Look for open issues".

[Piyushrathoree]

okay got it