Close Incident Permissions - User vs BPM

[Martyn Houghton]

If I remove the permission from a Users role to stop them from manually closing an incident via the 'Resolve' tab, will the BPM process trigger in the workflow by the user completing a manual activity still be able to close the request?

I am presuming the BPM process runs under a separate permission set/role?

Cheers

Martyn

[Guest Chaz]

That's right, @Martyn Houghton. This particular BPM action will be able to close the Request because it's granted the appropriate rights to resolve, close or cancel all Request types.

[Martyn Houghton]

@Chaz

Thanks for confirming. I'll look at implementing this as soon as we come out of our change freeze.

Cheers

Martyn

[Martyn Houghton]

@Chaz

I have removed the 'Close Incident' application right in our copy of the Incident Management User role, but the end users still have the ability to close the request manually rather than having to use the workflow to do it.

Our custom copied role

Standard role

 

Configured my Test use with only the roles below, but still able to close the incident via the Resolve action.

Is there another right that is giving this permission or is the system not honouring the application right.

Cheers

Martyn

[Martyn Houghton]

@Chaz, @Victor

My users still seem to have the option to close the request even though we have removed the application permission.

Cheers

Martyn

[Victor]

On 5/1/2018 at 12:57 PM, Martyn Houghton said:

My users still seem to have the option to close the request even though we have removed the application permission.

@Martyn Houghton apologies, missed your reply... .. are we sure there is no other role granting them this right? perhaps "Self Service User" role?

[Martyn Houghton]

@Victor

You where correct, it does appear that the hard coded 'Self Service User' does have the application right to 'Close Requests'. I will have to create our own copy of the role and remove the right and change the members of the roles.

Thanks

Martyn

[Victor]

4 minutes ago, Martyn Houghton said:

it does appear that the hard coded 'Self Service User' does have the application right to 'Close Requests'

That's because (I think sometime early this year, maybe Jan?) we introduced a functionality which allows self-service users to close and cancel requests via the portal... This being said, I am aware that @James Ainsworth has a change on his list to better cater for roles between self-service users and live app users (or something along these lines). He will be able to explain this better ... and add you as a connection to the change if needed  

[Martyn Houghton]

@Victor

Thanks. Now that I created an edited custom role, it has stopped my users from closing incidents through the front end, so they have to use the BPM.

Cheers

Martyn

[Victor]

Good news!!

[Martyn Houghton]

@Victor @Chaz

Slight complication, that by removing the right It has stopped the users manually closing the requests, but it has also stopped the BPM from closing the request as well. Is this a bug given that the BPM is supposed to still be able to do it?

Cheers

Martyn

[Victor]

49 minutes ago, Martyn Houghton said:

but it has also stopped the BPM from closing the request as well. Is this a bug given that the BPM is supposed to still be able to do it?

Not much good news then... Not sure, I need to have a look but on top of my head, yes, the BP should be able to...

[Martyn Houghton]

@Victor

Any update on why the BPM is no longer able to close the request? 

Cheers

Martyn

[Martyn Houghton]

@Victor

There appear to be setting to stop you resolving with activities but no closing. Our workflow gives them an activity to resolve the incident and the workflow will not proceed until the request has been resolved, so turning this on would not help either.

 

Cheers

Martyn

[Victor]

On 5/10/2018 at 4:24 PM, Martyn Houghton said:

by removing the right It has stopped the users manually closing the requests, but it has also stopped the BPM from closing the request as well. Is this a bug given that the BPM is supposed to still be able to do it?

@Martyn Houghton this is being looked at by devs... the BP action is tied to a user rights now so for the BP to be able to close the request the user (in which context the BP triggers/actions) needs to have this right... this applies basically for any BP action (update, resolve, etc...).

There is a wider internal conversation here so I will try and keep you posted...

[Martyn Houghton]

@Victor

Thanks. Hopefully there can be some way to elevate the permission of the BPM, where required.

Cheers

Martyn

[Victor]

@Martyn Houghton in the interim, to cater for your scenario, any chance you could possibly disable the closing action on the service/request altogether? Or you need it for other scenarios (e.g. a manager or an admin closes the request manually)?

[Martyn Houghton]

@Victor

At the moment the BPM closes the request after sending the Resolution email with the contents of the Resolution field to the contact. We do not leave our request at the status of resolved, as there is no automated closure process as there was in Supportworks.

As a workaround the analyst have the rights to close, and if they use it before the workflow activities are completed, I have to use Database direct to reset the status back to resolved so the activities and workflow can be completed and the automated email sent.

Cheers

Martyn

[Victor]

1 hour ago, Martyn Houghton said:

We do not leave our request at the status of resolved, as there is no automated closure process as there was in Supportworks.

Wait for status update with expiry? Would that work?

[Martyn Houghton]

@Victor

What user/permission context would the BPM us when the node expires? If it uses the owner, then we will still hit the same issue would we not?

Cheers

Martyn

[Victor]

2 minutes ago, Martyn Houghton said:

What user/permission context would the BPM us when the node expires?

In this scenario, since the action was not triggered in the context on one of your users/analysts, it will happen in the context of "System Business Process Manager" user (or a similar name, can't remember right now). This is a system user which should have all the required rights...

[Martyn Houghton]

@Victor

So if we expire the wait for status update at the minimum amount of time, i.e. 1 minute, the subsequent close operation would then take the system permissions and not that of the user?

Cheers

Martyn

[Victor]

Just now, Martyn Houghton said:

the subsequent close operation would then take the system permissions and not that of the user?

The "System Business Process Manager" is a user... but is a system user not one of the users (aka analysts) you would add to your instance... and yes, it will use the permissions of that system user not permissions of one of your analysts (using this term instead of users to differentiate the two). The reason is simple, because upon node expiry, the subsequent action(s) are not as a result of an analyst performing an action so Hornbill does not have a "context" to use... so it will use "System Business Process Manager" user context...

[Martyn Houghton]

@Victor

Will give it a try and see how it goes with the new requests logged after the change.

Martyn