enhancement BPM Switch to System Context Node

[Martyn Houghton]

Can I request an enhancement to have a new formal BPM process to switch the security context from the User to the System Context. In our example we have removed the User's permission to 'Close' a request, they only have permission to set it as 'Resolved'. This is because we have a number of post Resolution/Closure operations automated in the BPM. However at the moment we have to use the 'Suspend Await Expiry' with the minimum value of 1 minute to trigger the BPM security context to switch from the user who does not have permission to close the request to the system context which does.

Therefore having the ability to switch context without waiting would be a great help, as the users think the process is not working as it has not gone straight to Closed.

Cheers

Martyn

[Martyn Houghton]

@James Ainsworth @Steven Boardman

Is there any plans to provide a method to switch context without having to add in un-necessary delays?

This has become even more of an issue with us moving more processes into the Employee Portal, where the person logging the request may not have the permissions to undertake the processes in the BPM under their own context. We are having to put a 1 min delay in order to force it to switch to the system context in the BPM, so that the workflow does not fail.

Cheers

Martyn

[Guest Ehsan]

@Martyn Houghton,

The BPM engine is designed to run in the context of the logged-on person. A process is resumed upon a manual intervention, hence the Hornbill Automation is run in the context of the logged-on person. The "Wait for Expiry" Hornbill Automation creates a timer; this is a system event therefore the action is run in the context of the system account. The engine has been designed to this specification and it is not possible to simply selectively determine the context that a Hornbill Automation is run in, this does not meet the principles outlined within the Hornbill security model.

Could you please help me understand the scenario and the configuration you are working with. As I understand it based on our previous engagements, you do not use the OOTB Service Manager roles and use custom roles instead. At what stage in the process is the Request is closed? What task is performed by the Employee Portal user that then triggers the Request to be closed in the process? Which role(s) is the Employee Portal user assigned to (for those custom roles, it would help to know the rights granted)?

Ehsan

[Martyn Houghton]

@Ehsan

We remove the permission to close requests from user, as they where "accidentally" closing them without completing steps in the workflow. We use 1 min suspend to switch the context to the system user, so the BPM then has the permission to close the requests.

Users raise Change Requests via the Employee portal, but do not need to be a member of the Change Requests role as they are the consumer of the service not an analyst dealing with the change requests. As we automate a lot of processes in the CR ahead of the first 'Human' task which would end up being run as the user logging context and therefore not have the correct role/permission to undertake them. 

Cheers

Martyn

[Guest Ehsan]

@Martyn Houghton,

Could you please share a screenshot of the Employee Portal user's roles (the same user who raises a Change Request)? Where a custom role is assigned, could you please share a screenshot of the "Application Rights" tab for the custom role?

Ehsan

[Martyn Houghton]

@Ehsan

This is the error reported on the workflow of the request. The workflow updates the customer of the request after adding the user as a connection on the request.

User has the following roles.

 

They Idox specific one where created from the standard Hornbill ones when we first implemented as we need to alter some permissions compared to your standard ones. In this case the user is a full user and does have Change Management User access but the error still occurs.

Cheers

Martyn

[Guest Ehsan]

@Martyn Houghton,

Is this a different issue to the one you originally mentioned here?

To help us see the error in full, could you please follow the steps below;

• Open the Request list
• Press F12 on your keyboard in the Chrome browser
• Within the Chrome Console, click on the "Network" tab and add the text "?method=processGetState" into the filter box (As per my screenshot)
• Open the Request in question
• In the Chrome Console and the "Network" tab, you should see an entry for "?method=processGetState"; click on this entry and navigate to the "Response" sub-tab

Scroll to the bottom of the Response tab to locate the property "error" - could you please share the content of thisarea? Alternatively please feel free to copy/paste the entire Response tab into a notepad and attach as a reply.

 

[Martyn Houghton]

@Ehsan

If I restart the workflow it works fine, so it is the same issue of 'context'. The user logging the request in the Employee portal does not have the permissions to undertake the automated processes in the BPM which are done as soon as the request is logged.

Can you confirm at which point you want the network console output from, when the end user is logging it in the Employee Portal or when I open up the request with the broken workflow?

Cheers

Martyn

 

[Guest Ehsan]

@Martyn Houghton,

The output for the API when opening up the Request with the broken process would be perfect.

Ehsan

[Guest Ehsan]

@Martyn Houghton,

From your screenshot, I noticed that the "Idox Self Service User" role which I presume is a custom copy of the "Self Service User" role. Could you please help me understand why a custom version of this particular role was created? I can understand your scenario in relation to analysts accidently closing Change Requests which you have removed the rights for in the custom role. The "Self Service User" role aims to provide you with the basics to view requests as a Self Service user. A Self Service user does not have the Resolve/Close options, instead they can mark a request as having addressed their issue which ultimately resolves the request and then closes once feedback is submitted. The experience here is different to an analyst's. This approach means that everytime we add a new database table, you have to manually edit the role. Can I see a screenshot of the "Idox Self Service User" role?

Ehsan

[Martyn Houghton]

@Ehsan

Please see below the role permissions.

I will try to replicate the users issue and get the network console.

Cheers

Martyn

[Victor]

@Martyn Houghton @Ehsan sorry to jump into this, but I wanted to clarify something:

On 4/6/2021 at 4:11 PM, Martyn Houghton said:

The user logging the request in the Employee portal does not have the permissions to undertake the automated processes in the BPM which are done as soon as the request is logged.

As far as I am aware, the fact that the user logging the request has or hasn't certain rights, should not affect how the workflow acts... For example, assuming the workflow is configured to resolve the request but the user does not have the rights to resolve the request should not prevent the workflow from actually performing the resolve.