Implied Permissions as an End User, troubleshooting SR permissions

Adam_Dzyacky

I'm sure I'm overlooking something obvious here:

• End User in question is both an analyst/end user, so they have queue scope to Queue A
• Building an SR that is for a different department, it will belong dynamically to Queue B on submission
• The aforementioned end user/analyst can submit the SR, but can't see it in My Requests or looking it up in the console

Something about this just doesn't sound right - if they are an affected user, shouldn't they have implied permissions enabling them to view the request they submitted to a Support Group outside of their queue scope? Or does in fact a new queue have to be created allowing the end user/analyst in question the ability to view their own request?

It feels redundant and if anything problematic, as you can't create a Queue based on the Affected User = me. In which case, you might end up creating a Queue based on the Work Item Support Group and other qualifiers so they can view it. The inherit problem is by doing this, it means any user with access to this request could view someone else's request if they knew the Work Item ID.


Am I overthinking this?

Alex_Marsh

I think the issue here is the implied permission of the work items. I've seen something similar a few times when trying to scope things out.
Have you tried making sure that the user is in a role which grants read-only access to all work items? That way through the permissions they've got they should be able to modify their own work items and Queue A and see, but not be able to modify anything else

Adam_Dzyacky

Hey there @Alex_Marsh -

So I did that as a test (give read only access) and it absolutely works, but doesn't that by definition go against "good" security practice? Giving a large group of users access to a queue larger than what they should see but never the less providing access to it?

Again, not refuting your point/that this works but something about that just doesn't sit right with me.

Alex_Marsh

I agree it's a bit odd and doesn't sit right either. It must be something Cireson specific as examining the default 'End User Role' grant's no work item access to the user by default which would infer that on the standard Microsoft portal these permissions are not required?

john_doyle

@Adam_Dzyacky Can you find the guid id of the user either from PowerShell or from the CI$User table and then run this query against the ServiceManagement db?

exec spGet_MyRequests @UserId='guid of the user',@ShowInactiveItems=0

Does that show the Service Requests?
If you look at the definition of the stored procedure, we just list the work items where the logged in user is the Affected User. The query does not apply any scoping of the work items.