ShalilK Posted June 7, 2018 Posted June 7, 2018 Our instance has been upgrade to the latest release of Service Manager. Since the upgrade, parent requests are not being resolved when the corresponding child task has been resolved by a collaboration user (assigned the collaboration role). The child task gets resolved, however, the parent request remains open with resolution timer still active. This now has an impact on SLA's not being met even though the request (task) have been physically completed. Is there a fix/solution to the issue or do we have to have our Service Manager instance rolled back to the previously working release. Thank you Shalil
Victor Posted June 7, 2018 Posted June 7, 2018 27 minutes ago, ShalilK said: Is there a fix/solution to the issue We working to have it fixed. 27 minutes ago, ShalilK said: do we have to have our Service Manager instance rolled back to the previously working release. Not possible, there is no such concept with Hornbill architecture.
Victor Posted June 7, 2018 Posted June 7, 2018 @ShalilK the issue seems to occur because the task was actioned by a user who was not supposed to have access to that request (i.e. not being a member of a team that supports the service). Did you add this user to a team that supports the service recently? If so, does the error/issue occurs after the user(s) was(were) added to a team that support the service? If so do you have any examples of where the issue still occurs?
Victor Posted June 7, 2018 Posted June 7, 2018 @ShalilK just an FYI, the latest SM builds we tighten the security around requests access. From what I can see the issue occurs because the task was assigned to a user that was not supposed to have access to the request. If this worked before then this was a defect, which we fixed. I am sorry that the update broke the existing modus operandi but you were in fact exploiting (unintentionally and without being aware, of course) a security hole we had to fix. Hope this helps.
ShalilK Posted June 7, 2018 Author Posted June 7, 2018 Hello Victor I agree, one user did not have the support team assigned to them and work flow errors occurred after task closure. The user now has the support team assignment and the issue of parent request closure is still there (work flow errors being fixed after team assignment). I have just now created request SR00002735 for you to investigate.
ShalilK Posted June 7, 2018 Author Posted June 7, 2018 Further information: Request closure woks for out full service desk agents who have the 'collaboration role', 'incident management user' role and the 'service request user' role. It no longer works for collaboration users who have just the 'collaboration role'.
Victor Posted June 7, 2018 Posted June 7, 2018 @ShalilK ok, this is a different issue than the one I was looking into... thanks for clarifying. I applied a fix for this, can you please run another test with a user that only has "Collaboration" and "Self Service User" roles please?
ShalilK Posted June 7, 2018 Author Posted June 7, 2018 Victor, fix has worked. Thank you. FYI the working request is SR00002736. I will wait for the services to confirm all is well again over the next day or so. Can you please give me a brief update as to what was fixed?
Victor Posted June 7, 2018 Posted June 7, 2018 @ShalilK is all about rights... something we have been working on lately.. tightening security around roles and rights... Those users simply did not have the rights to resolve requests... something I raised internally for discussion as it seems it is a scenario we did not cater for... This being said, the fix I deployed now is not a permanent fix and it will reverted on the next application update. To cater for this (until the dev team reviews this functionality), please do the following: create a custom role with the following configuration: Details tab: Application Rights tab: No changes in any other tabs. Assign this role to all the users that are completing the "Resolve" tasks on your requests. This will ensure that if dev team did not cater for your scenario by the next update, the update itself will not reintroduce the issue. Once the dev team caters for the issue permanently we can then remove this custom role.
ShalilK Posted June 8, 2018 Author Posted June 8, 2018 Victor, there is an issue if I create and assign the custom role as detailed above. Assigning the custom role takes up a full Service Manager subscription licence. Barnet have purchased a set number of collaboration licenses and full Service Manager licences. We have already maxed out on the full licences. The collaboration users are not able to login if the custom role is assigned. The following message is displayed organizations subscription level for this application has been reached. Please advice how this issue can be resolved.
Victor Posted June 8, 2018 Posted June 8, 2018 @ShalilK ok, I understand. Right now you don't need to assign this role as it will work with the roles these users currently have: "Collaboration" and "Self Service User". So all is ok. I will ask the dev team to prioritise the permanent fix but for the time being you are ok. I will keep an eye on this issue to make sure no update will revert the fix I put in place until this issue is permanently addressed.
ShalilK Posted June 8, 2018 Author Posted June 8, 2018 For now, your fix works. You commented that any future upgrades will undo the fix. Until a permanent fix is in place, we won't be able to upgrade without reintroducing the bug.
ShalilK Posted June 8, 2018 Author Posted June 8, 2018 Thanks Victor, our comments crossed at the same time!
Victor Posted June 8, 2018 Posted June 8, 2018 @ShalilK ... As I said, I will make sure the fix stays in place until this is permanently addressed by the dev team...
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