Jump to content

Close Incident Permissions - User vs BPM


Martyn Houghton
 Share

Recommended Posts

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

Link to comment
Share on other sites

  • 3 months later...

@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

image.thumb.png.254cf5b5accb0173f4f5b4cf73de3fcd.png

Standard role

image.thumb.png.237d6cdda5c278a746e650939f06b151.png

 

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

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

Cheers

Martyn

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...
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?

Link to comment
Share on other sites

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 :) 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

  • 4 weeks later...

@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.
image.png.b1af55fc98fba17de18607ede31e6b82.png
 

Cheers

Martyn

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...