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
Added Device Groups to organize devices of a particular
organization
Configuration push updates now use the SIGUSR1 signal to reload
openwisp-config
The device list admin page now allows to search for location address
Changes
Backward incompatible changes
Since django-sortedm2m, the widget we use to implement ordered
templates, clears all the many to many relationships every time it
has to make changes, we had to stop deleting VpnClient instances
related to VPN templates on post_clear m2m signals If you wrote
any custom derivative which relies on calls like device.config.templates.clear() to delete related VpnClient
instances and their x509 certificates, you will have to update your
code to remove all the templates using their primary keys, instead
of using clear()
The default behavior for the resolution of conflicting management
IPs between devices of different organizations has been changed; by
default, in this new version, the system assumes it's using only 1
management tunnel for all the organizations, so different devices
from any organization will not have the same management IP to avoid
conflicts. The old behaviour can be restored by setting OPENWISP_CONTROLLER_SHARED_MANAGEMENT_IP_ADDRESS_SPACE to False
OPENWISP_CONTROLLER_BACKEND_DEVICE_LIST has been renamed to OPENWISP_CONTROLLER_CONFIG_BACKEND_FIELD_SHOWN
Device.check_management_ip_changed has been changed to private API Device._check_management_ip_changed
the signal is now always emitted on templates changes m2m
events, also if config.status is modified, with the
differences that only post_add and post_remove m2m events are
used, while post_clear is ignored, which fixes the duplicate
signal emission caused by the implementation of sortedm2m;
added action and previous_status arguments, which allow to
understand where the config_modified signal is being emitted
from, this allows more advanced usage of the signal by custom
implementations
Context variable follows template order: If two or more applied
templates have "default_values" with the same keys, then the context
variables of the template which comes later in the order will be
used
New credentials created with auto_add set to True will get added
to the existing devices in a background task. This improves the
responsiveness of the web application
Decoupled admin LogEntry from Template model
Device admin only lists relevant templates, i.e. templates that are
shared or belong to the device's organization
Made device name unique per organization instead of unique system
wide
Added time limits to background celery tasks
Bugfixes
Fixed a bug which caused VpnClient instances to be recreated every
time the configuration templates of a device were changed, which
caused x590 certificates to be destroyed and recreated as well
Hardened config validation of OpenVPN backend. The validation fails
if the openvpn key is missing from the configuration
Fixed a bug that caused issues in updating related Config whenever
a template's default_values were changed
Fixed pop-up view of CA and Cert not displaying data
Fixed config status stays applied after clearing all device
templates
Fixed VpnClient not created when multiple VPN templates are added
Fixed configuration editor raising validation error when using
variables in fields with maxLength set
Fixed connection notifications reporting outdated status
Fixed migrations referencing non-swappable OpenWISP modules that
broke OpenWISP's extensibility
Fixed bugs in restoring deleted devices using django-reversion
Fixed cloning of shared templates
Disallowed blank values for key_length or digest fields for CA
and Cert objects
Fixed template ordering bug in the configuration preview on Device
admin The order of templates was not always retained when generating
the preview of a config object