Enhancement requests for Export Policy BluePrint;
Tool required so that business owner can see, use and track policy better from a business perspective as well as Data Protection Admin.
Currently, it requires lengthy work to export the polices to a human readable format for business sign off (and a large Policy Requirement document to go with it). This will help speed up policy requirement’s and delivery (and system expansion).
The below has been noted using 14.6, however, 15.0 having a new feature has been discussed, unfortunately the feature that is being added is effectivly ONLY 'wgnpol export' with an additional -n to export a 'policy node'. This would not meet the requirement on any policy blueprint - the new -n will export 'all', not just the 'enabled' policy as required.
(also note -n is only export not import).
The options that used to exist when it was just a command line would be helpful to automate any BluePrint exports.
- Command line output
Required to automate export and scripted output on demand. Export policy Blueprint is extremely valuable for human readable format of policy for audit and business requirements, adding a command line option would enhance the use of this feature immensely.
Currently, features only allow export to XML with command line. The XML output is far too complex to be used by business staff, where an off-line copy of the blueprint is required for historical business audit purposes.
Command line would need to have options on what hierarchy branch is required for output and also full or sparse (enabled trigger data only see point 2.below). An option to only export a specific trigger would also be of value.
From the old policy for XLS file readme command line help:
wgninfra -run wigan/utils/policyxls/WriteXLS <policy> <file> <options>
where <policy> is a unique policy name or path starting at UserMaster/
and <file> is the name of an xls file which will be created.
<options> can be '-a' to output in ASCII, not unicode.
'-s<Filter> to output all triggers whose Trigger Name
setting contains <Filter>.
e.g. '-sCredit' to output all CCard Triggers.
2. Extended options for feature to only output 'enabled Polices' (not disabled or hidden triggers)
Currently exports all trigger information regardless of what is enabled or not. This makes the .XLS file one very large and slow to export, it also contains a lot of unnecessary information that the end users or admin are not interested in. Exporting policy to XML you at least get the option for sparse policy.
Note that currently on the blueprint export cell C1 has the text 'enabled' or 'Disabled' in the output. It is possible to write an xls macro to hide the sheets that have 'disabled' and exclude the first two sheets as the index and system setting sheets. But this is only a temporary measure as it requires loading the macro every time and has an issue with linked sheets for the 'document classification' that are shared for 'document classifiers' (see point4.)
3. Import exported XLS files
It would be good to be able to import a Blueprint as well as export one (similar to how import policy XML).
4. Output all the Parameters/settings on the trigger in one sheet not just link reference to another sheet.
Specifically for document classifiers triggers where document classification are often reused or not corresponding to the same trigger and classier number. Rather than only have the corresponding clarification and classifier with the same number being on the same tab and subsequent hyperlink to the relevant tab it would be better to have the correct parameters in the same tab (repeated/duplicate) the parameters.
Worst case have the classification as separate tabs, it is hard to track which classifier belong to which document trigger.
for example, a document classifier (trigger) which is disabled and has the document classifications parameters on the trigger, or the classification has no direct coloration to the classifier.
5. Some formatting issues/bugs with XLS (minor)
Some output texts are in the wrong columns, specifically there are text items that should be in column B but are in column A, specifically the following:
Text sting parameter label "Smart Tags" should be in column B but are in column A like all the other labels
Search Text and attachment triggers
Text sting parameter label "Included Search Text" should be in column B but are in column A like all the other labels
Text sting parameter label "Mail Details" should be in column B but are in column A like all the other labels