This post is the second part of a series of articles on privileges. The article will contain my loose observations and thoughts, as well as verification and testing of individual permissions at the application layer level.
My little sins
If I were to indicate the most common mistake I have made so far during implementations, then by far the most common sin I committed was not granting users rights or giving insufficient rights.
In retrospect, I can see the reasons for this. At the stage of my internal testing, I didn’t ask the customer to provide a test AD account. All tests were be done from my personal account, which had administrative privileges on the WEBCON preocesses and was the administrator of the SharePoint site collection.
It resulted in the fact that during the initial period of my implementations, I was not fully aware of how the permissions work and what exactly are the differences between my screen, my capabilities and the end-user using a given process. As a result, it happened that the first bug report received from the client was a request to grant permissions (to the site or to start the process).
Therefore, before submitting the process for testing, I recommend at least “some clicking stuff” the process from the level of the end-user account. You should also be aware of how exactly individual rights work. Thanks to this, we can avoid unnecessary bug reports and user’s frustration at the very beginning of user acceptance tests.
Let’s check individual permissions in an empirical way
A good exercise for a deeper understanding of permissions in the system is to verify the permissions allowed step by step. In the following parts, of this post, I will go through subsequent permissions verifying their capabilities and limitations. As part of this article, I will check the permissions at the application level. I will try to figure out how granted permissions affect on its screen and the possibilities in the system. For this purpose, I created a new AD account without any permissions (“webcon user” account).
If the user does not have any permissions (for any applications), he does not have access to the webcon portal (even if we give him the rights to the process!). It should be remembered that if we grant permissions to the process itself, you must also grant permissions to the application layer.
In order for a given user to have access to the application (only the presentation layer), it should be granted read-only access on the application authorization card in the WEBCON BPS designer studio.
After adding a given user in the read-only section he has access to the application.
Information for more inquisitive – permissions connected with application layers are contained in the WFConfigurationSecurities table. In this table, you can find permissions for all applications in WEBCON environment. The screen below shows the rights to the Legislation application (which has ID 13).
At this point, if we enter the application, you will notice that the user does not see any registered workflow elements or has no right to register any new elements due to the fact that he has no rights granted at the process or workflow level. Another article will be devoted to this topic. At the moment, however, let’s return to the remaining permissions at the application layer level.
Let’s check what happens when the user starts WORD with the WEBCON WORD addin without privileges to metadata.
After granting permissions – the given user (“webcon user” account) already has access to information about which attributes are stored within the application, but it is still not possible to generate a template and view what data is stored in the database (the generation button is unavailable).
Granting permissions allows the user to edit the portal for a given application. Thanks to this, portal designer can:
- Creating starters (but they cannot be started without process level permissions)
- Creating table reports and charts (but cannot see data without process level permissions)
- Creating dashboards
- Create embedded HTML of WEBCON components (HTML that can be embedded on other websites)
Finally, let’s check administrative privileges for an application.
After granting the user permissions to the “webcon user” account, I will try to run WEBCON BPS Designer Studio on this account. “webcon user” should have the right to manage processes with “application administrator” privilege.
Note: Remember that starting the studio (even in Lite mode) for a new user also involves using the WEBCON BPS Designer Studio license.
After granting permission for the “webcon user” account, I logged into his account and opened the studio.
After opening the studio, there will be shown only shared applications for that user. However, clicking on any of the processes causes an error. Any attempts to grant additional rights (both administrative rights at the level of all processes and the database) did not improve the situation. Only granting administrative rights at the global privileges allowed the new account to work in WEBCON BPS Designer Studio. I think that this is a bug and should probably be corrected in future software versions.
WEBCON BPS Studio Lite – Digression
I wonder if someone needs the light version of WEBCON BPS Designer Studio. The studio launched in the light version allows support only at the level of a given application/process. As a result, the user cannot create and modify data sources and the system configuration cannot be changed but the user still must have a license. In practice, the user using the light mode can only carry out simple maintenance tasks. Process administrator privileges are required for all other work.
In the above entry, I verified empirically the individual permissions for the end user account. The permissions were verified only at the presentation layer level. The topic of permissions at the level of the process itself has not yet been addressed and will be discussed in the next post.
Featured image: Business vector created by rawpixel.com – www.freepik.com