R80 Management architecture includes built-in revisions. A new revision is created automatically every time a user publishes his changes. The revisions' representation in the security management database is based on only the objects which were changed, not all objects, and therefore more efficient than R7x revisions.
1.) Use Case "dicard / revert changes"
Admin1 did some changes and published them. Admin2 did also some changes and check all the changes before Policy installation.
Admin2 recognise that Admin1 did a mistake, how can Admin2 discard the change from Admin1 before Policy installation?
For R80 or R80.10, there are some features which can assist with change management.
- install policy dialog lists changes in rules and objects since the last installation on the selected Gateway.
- Manage & Settings --> Revisions shows every revision made by any user. Clicking a revision shows the audit logs in the bottom pane. From the audit logs you can decide whether you wish to accept the changes or manually revert each change.
- R80.10 API has diff API method which allows selecting an object and seeing its history.
SmartWorkflow-equivalent features such as session approval will be added in our next releases.
2.) Use Case "revert Policy"
The much more important Use Case is to revert to an older Policy Revision with all the changes.
For Example: An Administrator use the API and change lot of Objects via script an publish at the last line.
In Verions prior R80 i can use the "Database Revision Control" what can i use with R80?
In case a policy installation was made after all these changes, with R80 and R80.10, there is an option to revert changes on the Gateway while keeping them in the Management server. This case is covered by the "Installation History" page. It is located inside Security Policies under the "Access Tools" in the bottom part of the left-side navigation. This view shows the occurrences of policy installation per gateway, and it has the option to install an older revision on a gateway without modifying the database in the Management server.
The other change management tools that I mentioned with your "case 1" can also assist in case of unexpected changes on the Management server, before installing a policy.