Martyn Houghton Posted December 27, 2017 Share Posted December 27, 2017 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 More sharing options...
Guest Chaz Posted January 2, 2018 Share Posted January 2, 2018 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. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted January 2, 2018 Author Share Posted January 2, 2018 @Chaz Thanks for confirming. I'll look at implementing this as soon as we come out of our change freeze. Cheers Martyn Link to comment Share on other sites More sharing options...
Martyn Houghton Posted April 17, 2018 Author Share Posted April 17, 2018 @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 Link to comment Share on other sites More sharing options...
Martyn Houghton Posted May 1, 2018 Author Share Posted May 1, 2018 @Chaz, @Victor My users still seem to have the option to close the request even though we have removed the application permission. Cheers Martyn Link to comment Share on other sites More sharing options...
Victor Posted May 10, 2018 Share Posted May 10, 2018 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 More sharing options...
Martyn Houghton Posted May 10, 2018 Author Share Posted May 10, 2018 @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 Link to comment Share on other sites More sharing options...
Victor Posted May 10, 2018 Share Posted May 10, 2018 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 More sharing options...
Martyn Houghton Posted May 10, 2018 Author Share Posted May 10, 2018 @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 Link to comment Share on other sites More sharing options...
Victor Posted May 10, 2018 Share Posted May 10, 2018 Good news!! 1 Link to comment Share on other sites More sharing options...
Martyn Houghton Posted May 10, 2018 Author Share Posted May 10, 2018 @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 Link to comment Share on other sites More sharing options...
Victor Posted May 10, 2018 Share Posted May 10, 2018 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 More sharing options...
Martyn Houghton Posted June 8, 2018 Author Share Posted June 8, 2018 @Victor Any update on why the BPM is no longer able to close the request? Cheers Martyn Link to comment Share on other sites More sharing options...
Martyn Houghton Posted June 8, 2018 Author Share Posted June 8, 2018 @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 Link to comment Share on other sites More sharing options...
Victor Posted June 8, 2018 Share Posted June 8, 2018 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 More sharing options...
Martyn Houghton Posted June 8, 2018 Author Share Posted June 8, 2018 @Victor Thanks. Hopefully there can be some way to elevate the permission of the BPM, where required. Cheers Martyn Link to comment Share on other sites More sharing options...
Victor Posted June 9, 2018 Share Posted June 9, 2018 @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)? Link to comment Share on other sites More sharing options...
Martyn Houghton Posted June 11, 2018 Author Share Posted June 11, 2018 @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 More sharing options...
Victor Posted June 11, 2018 Share Posted June 11, 2018 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 More sharing options...
Martyn Houghton Posted June 11, 2018 Author Share Posted June 11, 2018 @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 Link to comment Share on other sites More sharing options...
Victor Posted June 11, 2018 Share Posted June 11, 2018 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 More sharing options...
Martyn Houghton Posted June 11, 2018 Author Share Posted June 11, 2018 @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 Link to comment Share on other sites More sharing options...
Victor Posted June 11, 2018 Share Posted June 11, 2018 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 More sharing options...
Martyn Houghton Posted June 11, 2018 Author Share Posted June 11, 2018 @Victor Will give it a try and see how it goes with the new requests logged after the change. Martyn Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now