Jump to content

Recommended Posts

Posted

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

Posted

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.

  • 3 months later...
Posted

@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

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

Posted

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

image.thumb.png.15ee6996b483c321f79e597704183cf5.png

Thanks

Martyn

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

Posted

@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

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

  • 4 weeks later...
Posted

@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

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

Posted

@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)?

Posted

@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

Posted
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?

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

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

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
×
×
  • Create New...