NOTE: Product edition NiceLabel LMS Enterprise is required for this feature.
Revision control system in Control Center is designed for multi-user environments and supports concurrent operations on files that are located in the Document Storage. While a certain file revision is in use in the production environment, the changes can already be applied to the next revision.
To prevent any changes on a file that are done by more than a single user at the same time, the file locking system is in place. If users need to update the existing Automation configuration, they have to reserve the file for themselves. The file is checked out. During this time, the currently approved file revision can still be used uninterruptedly in the production. When users are done with the updates, they submit the new file version back to Document Storage. The file is checked-in.
Figure 18: Document management controls in Automation Builder
With release 2017.3, the check-in and check-out operations can be accomplished directly from Automation Builder. The application is equipped with a new ribbon tab named “Document Storage”. It allows you to quickly manage check-in and check-out operations and to access this particular configuration in the Document Storage.
A new shortcut to the Document Storage is also available when selecting File > Open command.
Figure 19: Quick Document Storage access from Automation Builder
When opening a file from Document Storage without checking it out, the file remains in the locked read-only state. Its modification is not possible.
NOTE: Product edition NiceLabel LMS Enterprise is required for this feature.
If a file in a Document Management System should not be used at any point during its life cycle, users now have the ability to decommission such files. Decommissioned files cannot be used in production but they are kept in the system for future use or audit purposes. The decommissioned file is still visible to users with read/write access to the folder. You can continue updating the labels and other documents and advance them through approval process. Decommissioning a label prevents access to it from print operators in production but does not delete the actual document.
Decommissioning can be a permanent or temporary action. Should you need the decommissioned file again later, you can recommission it. The file is then again accessible by the production users.
By default, Administrator and Approver profiles are allowed to decommission a file. To allow other user profiles to perform this action, you can configure it in Administration.
Figure 20: Permission to decommission the document is configurable in Administration
After you have decommissioned the file, an image appears next to the file icon in the Document Storage indicating that the file has been decommissioned. At this point, production users will not see the file any more.
A file can be decommissioned even if it is not currently published. This option is available also for files that are still in the approval process or have been decommissioned in the past.
Figure 21: The decommissioned file can be recommissioned
NOTE: Decommissioning requires authentication to be enabled on Control Center.
NOTE: Product edition NiceLabel LMS Enterprise is required for this feature.
By default, only Administrators can remove a published file from the Document Storage. In NiceLabel 2017.3, the Administrator can allow any other security profile to remove the published files as well.
To grant the selected profile the right to remove published files from the Document Storage, you can configure the permission in Administration tab.
Figure 22: Permission to remove published document is configurable in Administration
Once you delete a document, it is not actually removed from the Document Management System. The document is safely stored in the internal “Recycle Bin”. Only Administrators have permissions to restore the deleted files or permanently purge them from the system.
Figure 23: Using “Recycle Bin” options in Document Storage System to restore or purge the deleted files
NOTE: Product edition NiceLabel LMS Enterprise is required for this feature.
Document Management System already includes a workflow process that requires two independent approvers to review and approve the document before it is published and sent to production.
NiceLabel 2017.3 upgrades the process with the ability to define the order of approval steps. You can define separate groups of people for first and final document approval.
To reach the approved status, a unique member of both approval groups must approve the document.
Figure 24: Configuration of two-step label production approval process
If using file-based data sources such as Microsoft Excel and Microsoft Access files for Web Printing labels or solutions, you no longer have to use full path to the data file. Instead, you can use relative path to the data file, with path origin starting in the folder where label or solution file is stored.
For example, if you have a solution stored in a folder Project\Solution and have your Microsoft Access database in folder Project\Database, the relative path to the database is ..\Database.
NOTE: NiceLabel recommends using Microsoft SQL or other server databases to be used with Web printing solutions.
The “Execute SQL Statement” action executes the provided SQL statement on the database and returns a result. If you execute SELECT statement, the result is a dataset of records formatted as a CSV structure.
With NiceLabel 2017.3, Automation can parse the returned dataset for you. If you enable the “Iterate for Every Record” option, the “For every record” node appears under the action. Inside the node, automatic mapping takes place between the fields returned with the dataset, and variables defined in the label. You no longer have to manually configure any “Structured Text” filter to parse the data.
NOTE: This action is available in NiceLabel PowerForms edition as well.
For easier understanding, see the screenshot below. When running the statement “SELECT * FROM Products”, the fields “Key”, “GTIN”, “Id” and “Name” are returned in the dataset. Automation extracts the fields from the dataset and assigns their values to the label variables that have the same names as fields in the dataset. There is no need to configure any filter or to configure any manual mapping between fields and variables. All actions within the “For every record” action are executed once for each record in the dataset.
Figure 25: Iteration for every record automatically assigns field values to label variables without custom filter
Of course, the prerequisite here is that field names in the dataset and variable names in the label match. You can adjust your SELECT statement to return aliases of field names that match the names of variables, e.g.:
SELECT column_name AS alias_name
FROM table_name
You can enable authentication for an HTTP trigger and thus only allow access to applications that authenticate themselves using a correct user name and password. In previous versions, NiceLabel Automation already supported a single general user name and password that all connecting clients had to use.
In NiceLabel 2017.3, you can grant access to the HTTP trigger to multiple users that are members of a specific Application Group. This simplifies user management in complex environments, where security practice advocates are using personalized user names and passwords, and not a shared one.
Figure 26: Users from Application Group “User Group A” can connect to HTTP trigger
Each connecting client is assigned with a unique user name and password. You can add the user as Application User using Control Center Administration.
Figure 27: Users “Frank”, “Gerd” and “Saso” can all connect to HTTP trigger using their credentials