You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The details of this shall be discussed further before proceeding.
We shall implement two new admin actions and related model methods which perform the following:
1. Deactivation
we shall make all the field of a deactivated device readonly
if the device has any related OpenVPN template with certificates, the certificates shall be flagged as revoked
removes any config and template from the device, ensuring the revoked certificates do not get deleted (because we need those to be in the CRL)
sets the config status to deactivating (this is a new status)
once the config is applied by the agent (we must make sure it's deactivated) the config status should be set to "deactivated" instead of "modified"
once the config is set to deactivated, the controller HTTP API should return 404 for these devices, so that the agent stops asking for the checksum
I think we should hide the delete button of the admin and show "deactivate" instead, we could show the delete button only if the config status is "deactivated" or if the device does not have a config object
we should add the deactivate admin list action, if we can add it before the delete action it's better
the admin action which deactivates multiple items at once must deal with the case in which one or multiple devices are already deactivated in a graceful way, informing the user and without failing
ensure we emit a signal when this happens, I believe a config status change is emitted but let's double check (so we can listen for this event in other modules)
we will also need to update the API to prevent changing any details on the deactivated devices
2. Activation
add an admin action which sets the config status to applied;
it must deal with the case in which one or multiple devices are already activated in graceful way, informing the user and without failing
Why this feature?
Right now deleting a device does not remove the configuration from a device, so a device which gets deleted from OpenWISP Controller can still potentially connect to the configured VPNs.
On the OpenVPN side, we must recommend configuring the CRL (needs to be downloaded periodically from OpenWISP and when a change is detected the VPN conf should be reloaded).
The details of this shall be discussed further before proceeding.
We shall implement two new admin actions and related model methods which perform the following:
1. Deactivation
2. Activation
it must deal with the case in which one or multiple devices are already activated in graceful way, informing the user and without failing
Why this feature?
Right now deleting a device does not remove the configuration from a device, so a device which gets deleted from OpenWISP Controller can still potentially connect to the configured VPNs.
On the OpenVPN side, we must recommend configuring the CRL (needs to be downloaded periodically from OpenWISP and when a change is detected the VPN conf should be reloaded).
Related to openwisp/openwisp-monitoring#445.
The text was updated successfully, but these errors were encountered: