We appreciate you taking the time to vote and add your suggestions to make our products awesome! Your request will be submitted to the community for review and inclusion into the backlog.
We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.
For more information around feature requests in the Cireson Community click here.
We recommend reviewing what is submitted before posting, in case your idea has already been submitted by another community member. If it has been submitted, vote for that existing feature request (by clicking the up arrow) to increase its opportunity of being added to Cireson solutions.
For more information around feature requests in the Cireson Community click here.
Security Granularity for Request Offerings Within a Service Offering
Keith_Christofferson
Partner Adept IT Monkey ✭✭
We've been defining Service Offerings by who is providing the service (e.g. IT, HR, etc) meaning all Request Offerings for things IT would do, are in the same Service Offering. In the built-in portal using Security Roles, and Catalog Groups we can scope Request offerings to specific Security Roles, and depending on who you are, you see special Request Offerings for your role, in addition to all the services available from IT for everyone. In the Cireson portal I was informed by a technician that users can see any Request Offering within a Service Offering they have access to; this means we'll need to instead define our Service Offerings by who is making the request, as opposed to who is providing the service. It would be nice if the Cireson portal handled this in the same way as the default portal, and Catalogue Groups could be used to scope access to both Service Offerings, and Request Offerings.
67
Comments
Not sure where that information came from but that's not quite correct. What you are doing sounds great and you can scope out certain ROs to different people within one SO. In order to see an RO, it must be in a SO, a user must have access to the RO and it's SO via a catalog group and both must be published.
Hope that helps,
Geoff
@chris_ross are you able to confirm or advise if this one is still on the backlog to change permissions here?
So, that is not the behavior I'm seeing. I've confirmed, that in the Silverlight SCSM portal, security functions as I expect (as you describe) but in the Cireson portal, it does not. When I opened a ticket with support to figure it out, I was told that security scoping is not granular within a SO, and that I should split my SO's based on who I want to see the RO's. As with Joe, I'm super curious, if you know how to do this, please let me know, I'd love to not have to change all my existing SO's.
That being said you can have multiple SO with the same name and different permissions if you desire to scope sections of the SO down to a smaller number of folks.
Right, I just have all the security already setup, and if a client would be going from the OOB portal, to Cireson, not having to rework security at all would be nice.
I have been rebuked by my colleagues. I stand corrected, I'll up-vote as this would be nice seeing as this is how it thought it worked.
Apologies for the miss information.
Geoff
No problem! I'm pretty sure it worked in my environment in V2 (at least for users in the same domain as the SCSM server), I just assumed it'd work in V5 as well. I'll probably just end up reworking SO's for now as a work-around and recommend the same to and clients.
My manager has asked me for this as I told him scoping was there (wasn't aware of this limitation at the time of course). So not sure how I am going to do this for him now.
I updated your service support ticket - please let me know if you have any additional questions/concerns.
Thanks,
Steve
metions.
So depending how you are currently catalog scoping. You would want to remove your "internal offerings" from any of the the end service offerings you have scoped to your end user role. Or create new catalog groups for your end users and scope to your role.
Do we have any ETA on this being fixed?
We are currently using the method described by using multiple similarly named Service Offerings, but have come across a few issues with this method:
URL's are unique for the same RO that is in different SO (because the URL is based on a combination of both RO and SO GUID). This makes providing direct links to RO a contextual nightmare for our Help Desk.
It is difficult to maintain, as in our environment the desire is to have an SO with a name that does not also include the scope, as this would look sloppy. But for our Help Desk, this means they are unsure which of multiple similarly named SOs contains the correct RO, and have to open the RO to check the SO’s description, which is where we express the scope.
Now we could re-work the Service Catalog to show the SO’s description, but that isn’t nearly as clean as just having the Catalog Group’s scope of ROs taken into consideration.
An ETA would be really appriciated as it would save us a great deal of time and effort.
Thank you Seth, I really appreciate it.
If it helps for context, here are some examples of the struggles. In our environments, the Request Offerings available can include scope based on Security Groups that include:
The trick here is that some ROs need to factor in multiple of these categories at one time. This is a handful, but can be done with AD Groups and Catalog Groups. Without being able to scope down to the RO, you can imagine how out of hand this could get.
Right now we've limited scoping to a bare minimum to avoid the issue, but this has resulted in creating RunBooks that check the Affected User's membership, and sometimes outright cancel the SR that's generated because the End User shouldn't have submitted it. Not a great end-user experience, and we'd love to have them just not see the stuff they shouldn't.
Any update on this? I am being ask to again add additional security scoping which is going to result in another round of headaches. As these could all be resolved if RO's where able to respect the existing security scope. This is becoming more and more of an issue for us.
If opening a feature request on the support site would apply additional pressure to this, I will gladly do so. This is a major need within our organization.
It's possible we will be revisiting some scoping performance changes in the near future, in which case this would be a part of that process. Outside of when that time comes, this request is not currently one of the top requests and so hasn't been picked up on it's own for implementation at this point.
Is there any update on this? I was hoping to be able to restrict individual RO within a SO rather than creating lots of SOs. I was hoping this might give us some alternative options.
This feature is far overdue, we would also love the ability to scope individual RO's instead of SO's in the portal!😊
Hopefully this gets more and more votes.
Please, implement RO-level scoping. How can global companies offer same ROs with country-specific fields to their offices without this?