Request Offering - History - Unathorized Access
Hello,
I have been having a continuing issue with 1 RO, and I was just wondering if anyone had seen this before.
When a customer tries to use this particular RO then they go to save it, it gives unauthorized access popup and will not save. I have recreated it several times, as well as the template. Today I looked in the History section of the RO and found this
Answers
This has caught us a few times were we create a new template and RO, then realize we did not provide the user (their user role) access to the template.
I found that some SR tickets are being added to the History information by SCSM my service account. I wanted to upload a screen capture but there is no way to do it to this Question.
@Brian_Wiest No there are not configuration items in either the template or the RO.
The History shows items being added by the SCSM Service Account -
Relationship Changes:
Add/Remove Relationship Class Item
Add Work Item relates to Request Offering SR261309: Additional IT Equipment (AITE)
There are several entries on multiple days with this information but different SR#s
What I was referring to/looking for is on the initial submit do you see something like this.
Typically when users have access to the RO/SO etc but do not have rights to edit configuration items you get the failure.
So when it fails what shows in the portal\logs\console.log
If you have an SMA runbook activity in the template, for example, and that runbook has the author defined, then end users would need permission to create the runbook activity to author relationship. End users should have implicit permission to create any relationship which relates to the work item being created. You just need to watch for relationships being created between related objects. Mostly they work, but if you have any custom relationships you may have to give the users implicit permission to create the relationship. In the example of the runbook activity, you could simply remove the author entry from the template. If the relationship is not defined on the template or mapped in the request offering, it will not be created, so you just need to check those relationships which are defined.