eNMS 3.3

• new service instance bug: fixed
• stale selection bug: fixed
• Stagger Start/End so that the user can tell that there are multiple boxes there?: Done.

• GOTTY_SERVER_ADDR -> ENMS_SERVER_ADDR (also used for the notification system now)
• Refactoring of the Vault code (should be transparent)
• Refactoring of the JavaScript architecture (should be transparent)
• You can now edit a workflow from the workflow builder page
• New feature: duplication (objects, services, and workflows)
• Refactoring of the logs window (logs and "compare" merged into one window)
• Improved notification system with summary, link to logs, attached text file for email.
• Bug fix for the migration system. Note that if you want to migrate data to a new VM, you'll need to replicate the Vault too, because I don't export passwords (I consider that since there are in the Vault, there is no need too, and anyway it would be bad practice to have all passwords in clear-text in the export files)

• Also, if 'Clear Logs' has been run already on those logs when the user clicks on the link, open the same browser Tab but with a single message: 'Automation Job results have already been removed from this server'
• deprecation warnings hvac / deprecation warning TextField -> StringField
• import/export: add option to replace existing inventory... + add option to update pools
• remove create account page
• prevent user from running a job that is already running
• For pool filtering-> Admin Panel -> Pool Filtering - when I make a selection, save it and return to the admin panel, it again says 'all devices'. Can you persistent the selection?
• REST password in the vault

eNMS 3.2

• retry mechanims: https://enms.readthedocs.io/en/latest/services/service_system.html#retry-mechanism
• custom properties in dashboard: https://enms.readthedocs.io/en/latest/inventory/objects.html#custom-properties
• environment variable to bypass example creation: https://enms.readthedocs.io/en/latest/base/installation.html#default-examples
• mattermost + mail notification system: https://enms.readthedocs.io/en/latest/services/service_system.html#service-notification
• pool-based database filtering system (from the admin panel) : https://enms.readthedocs.io/en/latest/inventory/pools.html#use-a-pool-to-restrict-all-of-enms-to-a-subset-of-objects
• heartbeat : https://enms.readthedocs.io/en/latest/event_driven/rest_api.html#heartbeat

eNMS 3.1

• Migration system
• Real-time update of the workflow
• Start / End task in a workflow
• Minor fixes

eNMS 3.0

• Custom services

• Existing services: the existing "default" services have been enhanced to allow variable substitution and python code execution within the payload fields of each web form. For example, this allows the ReST call service URL to iterate across each {{device.name}} as it is called on a selection of inventory devices.

• eNMS is now configured to use a PostgreSQL database + a Hashicorp Vault to store sensitive information such as network credentials.

• Automatic topology import from OpenNMS (REST API) or Netbox (with pynetbox).

• Web SSH: you can now SSH to your switches/routers directly from the web UI with a web-based SSH solution. For instance, from the geographical view, you can click on a device, then click on "Connect" to open a web SSH terminal. This works even if your network is behind a jumpserver, as long as eNMS is installed on the jumpserver. Optionally, eNMS can automatically authenticate you (credentials are fetched from the Vault)

• Event-driven automation: Services and workflows can be triggered by an external event in two ways: via a call to the REST API with the name of the service/workflow, or upon receiving a Syslog message that matches a preconfigured rule.

• There is a dockerfile to start the application as a container, and a docker-compose file to start it with PostgreSQL database and Nginx web server.

eNMS 2.1.0

• Custom scripts: possibility to create its own script in python: they are automatically integrated into the interface. Examples of such custom scripts.

• Workflow refactoring: a workflow is no longer a graph of scripts, but a graph of tasks. A task is a set of scripts applied to a set of devices. This means that a single workflow can apply change to different devices.

• openNMS support: eNMS can query the ReST API of openNMS to retrieve all nodes.

• eNMS ReST API. eNMS has a new ReST API, which can be used both for querying objects, and executing a task remotely:
  docs: https://enms.readthedocs.io/en/latest/automation/rest.html

Issues solved in this release:
#70
#69
#68
#67
#66
#65
#63
#76

eNMS 2.0.1

• eNMS now supports sending Ansible playbooks.

• Introduction of workflows. Scripts (netmiko, napalm or ansible scripts) can be combined together to form a "graph of scripts".

• Before, network visualization (display the network on a world map or via a force-directed drawing algorithm) and network automation (scheduling netmiko/napalm scripts) were independent features. Now, all the automation is done graphically, i.e you can schedule a script/workflow by selecting the target devices directly from the graphical view (from the world map, or the force-based graph drawing).

• A task can be scheduled to run a command periodically and store the outputs of a command in the database. eNMS then creates a line-by-line diff of the outputs between any two versions.

eNMS - fix bugs after first release

• fix bugs regarding object creation / deletion / update
• fix TACACS implementation
• encrypt all passwords in the database with passlib

eNMS - v1

login system + tacacs+ authentication
object overview
object creation
object deletion
object filtering
visualization with leaflet and vis
netmiko / napalm / yaml / jinja2 automation system
script creation + scheduling
script execution system with APScheduler and multiprocessing
no automatic NAPALM commit after load conf