locked
Queues to restrict work items RRS feed

  • Question

  • Hi,

    Is it possible to use queues to restrict users from viewing some workitems? I have created a queue that includes all service requests with area 'process' and I dont want anybody to be able to view these items, exept for those that are members in a specific user role.

    In other words, is it possible to have a user role based on incident resolver (or other), be able to view all incidents, CR and Service request exept for these specific service request?

    I guess if you start out by hiding _all_ workitems and then showing queues per user role this would be possible, but then we would need to group _all_ workitems under queues. I just want to hide this specific service request from all users exept those members of a specific user role.

    Kind Regards,

    Ezequiel Osorio


    E.O
    Wednesday, January 4, 2012 2:51 PM

Answers

  • Are you using SCSM 2010 or 2012?  One of the problems I faced in 2010, which I assume would be across the board, is that once you start using Queues, you now have to use Queues. 

    So, if you are attempting to 'hide' a certain type of work item from a group of users, you must give them access to everything else.  It's not as simple as saying (insert user role here) cannot access and (insert user role here) can access.

    You would need to create Queues for-

    1.) 'All Change Requests', 'All Manual Activities', 'All Review Activities', Etc

    2.) Queues to separate out your available areas within your service requests.  So if you have 11 available areas and you want everyone to have access to 10 of them, then you would create 2 Queues-
    a. The criteria would be similar to 'service requests where the area = 1, or 2, or 3..., or 10
    b. The criteria would be similar to 'service requests where the area = 11

    You could then Create a User Role, based on 'Incident Resolvers', and during creation, grant that user role access to all of the queues listed in #1, and to queue #2.a.  That set up would give any users that are members of the new user role access to all service requests except those where the area = 'process'.

    This, however, only gets you part of the way.  As I said, once you start using queues, now you have to use them.  The permissions within SCSM 2010 are cumulative, not restrictive.  Meaning, if User A is a member of your new user roles which limits access to queue number 2.b, and a member of an out-of-the-box user role, or a different user that that allows for access to all queues, then you have just defeated your purpose.

    So, your user roles must be set up to 'stagger' the permissions.  For example, if you have a user role that is based on 'Change Initiators' then you would want that user role to have zero access to 'Service Requests'.  You would do so by limiting that user role to accessing only the queue containing 'All Change Requests'.

    Hope that helps.

    • Marked as answer by E.O Friday, February 3, 2012 12:47 PM
    Tuesday, January 17, 2012 9:22 PM

All replies

  • Hey

    to my knowledge, I guess you can only exclude specific objects, not other dynamically created queues.

    regards
    Marcel


    SCSMfaq // Blog --> http://blog.scsmfaq.ch // Twitter --> #scsmfaq // Business --> http://www.itnetx.ch
    Thursday, January 5, 2012 4:44 PM
  • Hi Queues are scoped by class so plan you role based security by class.

    You cannot mix class types in queues and views but you can select different class type queues during security role creation (Note the out of the box roles only allow you to assign members ; AD users or groups).

    Create a custom role based on the Service request analyst role and select the restricted queues you have created by class type.

     

    Sunday, January 15, 2012 5:58 AM
  • Are you using SCSM 2010 or 2012?  One of the problems I faced in 2010, which I assume would be across the board, is that once you start using Queues, you now have to use Queues. 

    So, if you are attempting to 'hide' a certain type of work item from a group of users, you must give them access to everything else.  It's not as simple as saying (insert user role here) cannot access and (insert user role here) can access.

    You would need to create Queues for-

    1.) 'All Change Requests', 'All Manual Activities', 'All Review Activities', Etc

    2.) Queues to separate out your available areas within your service requests.  So if you have 11 available areas and you want everyone to have access to 10 of them, then you would create 2 Queues-
    a. The criteria would be similar to 'service requests where the area = 1, or 2, or 3..., or 10
    b. The criteria would be similar to 'service requests where the area = 11

    You could then Create a User Role, based on 'Incident Resolvers', and during creation, grant that user role access to all of the queues listed in #1, and to queue #2.a.  That set up would give any users that are members of the new user role access to all service requests except those where the area = 'process'.

    This, however, only gets you part of the way.  As I said, once you start using queues, now you have to use them.  The permissions within SCSM 2010 are cumulative, not restrictive.  Meaning, if User A is a member of your new user roles which limits access to queue number 2.b, and a member of an out-of-the-box user role, or a different user that that allows for access to all queues, then you have just defeated your purpose.

    So, your user roles must be set up to 'stagger' the permissions.  For example, if you have a user role that is based on 'Change Initiators' then you would want that user role to have zero access to 'Service Requests'.  You would do so by limiting that user role to accessing only the queue containing 'All Change Requests'.

    Hope that helps.

    • Marked as answer by E.O Friday, February 3, 2012 12:47 PM
    Tuesday, January 17, 2012 9:22 PM
  • Hi,

    Yes thanks, it does help to explain how this is working. We´ll problebly hide the information in some other way since this is to much administration to work with. Just not easy enough!

    Thanks,

     

    Kind Regards

    Ezequiel Osorio


    E.O
    Friday, February 3, 2012 12:47 PM