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.
Current Status for Security Scoping an RO to SO within the Portal
Peter_Forster
Partner IT Monkey ✭
Hi,
there was already an discussion about this topic but nothing new since months: https://community.cireson.com/discussion/495/security-granularity-for-request-offerings-within-a-service-offering
What is the current status of this?
When will this feature implemented?
0
Best Answer
-
seth_coussens
Member Ninja IT Monkey ✭✭✭✭
Hey Peter, the way most customers work around this currently is by looking at the RO as a member of the SO with the SO determining security. You can actually have duplicate SO names and these will be 'merged' in the portal for any users that are in identically named SO groups. So it would look something like this...
Special SO
- RO 1
- RO 2
Special SO
- RO 1
- RO 3
If USER1 had access to the first Special SO but not the second he would see only RO 1 & 2, while USER2 has access to both SOs and would see RO 1,2, & 3.5
This discussion has been closed.
Answers
At these meetings, they go through the top feature requests that have been up-voted by the community.
If the idea has plenty of votes and\or is simple to implement it goes on the backlog to be developed and the status of the Feature request will change to reflect that.
If the idea is a little harder to implement but have plenty of votes and we think it is a great addition, we will also add it, but the dev cycles just may be more.
Finally, if an idea does not fit in to our product focus or what we want to achieve out of the solution, regardless of votes, we may kill the feature request and not implement it. But either way will will update the status to ensure people know what the status is.
I like this idea and it has had a good number of votes. I've voted for it.
If you know others in the SCSM community, maybe suggest to them to vote on the idea if they think it is worth it.
I hope this has answered your question.
Hi,
wow - this is interesting. I had an open IR about this: IR35713 and here the engineer was telling me that this issue will be adressed around Version 5. Now V7 is realeased and currently there aren't enough votes to implement this feature at all.
This is something I find very interesting. Are customers not required to Scope RO's based on SO's. How do the scope RO's for an enduser?
Special SO
- RO 1
- RO 2
Special SO
- RO 1
- RO 3
If USER1 had access to the first Special SO but not the second he would see only RO 1 & 2, while USER2 has access to both SOs and would see RO 1,2, & 3.
Thanks for this information. Our largest customer has currently hundreds RO's scoped to many many SOs. This whole system was built on the old Silverlight MSFT Portal where the security scoping on SO/RO was possible. Now we have waited to see this functionality in the Portl and it sounds like we need to redesign the security and build many more SO's to scope down this.