Has anyone encountered a situation where you required that everyone in your Service Desk to administer all incidents? For example: If someone went on vacation and they forgot to reassign their incidents and someone else needed to pull the incidents from that other worker, how is this accomplished when dealing with workers in a custom group.
These are the configurations of the group:
- Custom Group Name: Desktop Team - Permissions: Copy permissions from Support II - Workers are assigned to the Desktop Team - Group Permissions: Can View, Can Edit, and Can not Administer - User Permission: Can View, Can Edit, and Can not Administer
Support II has permissions to administer incidents but under a custom group this is not equal.
Thank you for you time!!
The first thing you need to do is add the group to the Application Properties in Process Manager. To do this go to Admin - Data - Application Data. Click the lightning bolt for ServiceDeskSettings and click Edit Profile Definitions. You will see the following screen. Click Next.
Scroll to the bottom of the Profile Definition Values and click Add Definition Value. Add your group information following the below example and click save:
You should now see your new group name at the top of the list of the other groups:
Scroll down and click Finish once you confirm. On the Application Properties Profiles page click the lightning bolt to the right of ServiceDeskSettings and click Display Definition Values. On the ServiceDeskSetttings page click the lightning bolt and click Edit Values. On the Edit Instance page scroll down to the User Groups Category and find your new group. Change the text box to the right of the group name from SD.IncidentManagement to the group name as seen below, scroll down and click Save.
Your group will now be available to your Workflow Components. Open Workflow Manager and the SD.IncidentManagement workflow. Open the Setup Process component under the Primary Model. Copy the data stream for the Service Managers permissions including the exception and log components, make some room above and paste them. You will need to do this for every group you want to grant permissions to. Change the GetGroupByName - Service Managers name to reflect your group name. In this case I would name it GetGroupByName - Test. Open the component and click the ellipses under Parameters. Click Remove to remove the current Process Variable referring to supportii and then click Add. Expand [Profile Properties] and find your group name select it and click OK.
Verify your group name is now the selected Process Variable and click OK and then OK again. Next click on the Outputs tab and verify the Result is GroupInfo and click OK.
Change the name of the AddPermission.... component to your group name. In this case it would be AddPermissionToDocumentCategoryTest. Change the Component setting of the Exception Trigger By Component components to GetGroupByName - Test and AddPermissionToDocumentCategoryTest. You can repeat this for any other groups you want to automatically give Admin rights to.
Next do this in the Setup Process of the CreateIncidentAdvanced Model. Publish, restart IIS and Server Extensions and test it out.
I put this together quickly so let me know if I'm missing anything. I hope it helps.
I have done that as well but I find that not all permission are transferred. It is a bit frustrating. I would greatly appreciate your input on this. Thanks again for your reply. I hope that Symantec documents the heck out of Service Desk 7.5.
So that is where Dave is this week. Ok cool. Dave is the best!!
You're right, it's not going to be supported. The problem is that Symantec's recommendation is to add the users to the Support II group which doesn't seem to solve the problem in my experience. I don't know where the instructions are but if you don't find it I can put something together for you tomorrow.
No.. actually I'm in Dallas. Dave Ramazetti with XCEND did our 7.1 setup. I've been working with him this week on issues with SD. We're at a point now that if we don't see a great improvement in 7.5 we're probably going to find something else.
I tried modifying the Setup Process in the primary model and the CreateIncidentAdvanced and it worked somewhat. The issue here is that this would be considered a customization that is not supported by Symantec. I noticed a while back that an article I used to reference is no longer available which outlined the process you speak of. Are you aware if there is another location where I can find these intructions?
btincher I appreciate the feedback and help. I did some testing and is seems that giving Support I rights to a custom group and define the permissions manually, you can indeed lock down the access to certain tickets in other custom groups. The permission that limits the sight of these sensative incidents was found to be the Workflow.ViewUnassignedTasks can help in this situation by disabling navigation to tasks or processes that you are not permitted to view.
I added all my custom groups to the Setup Process components of the Primary model and the CreateIncidentAdvanced model. Any groups I don't want to have admin rights I didn't add to these workflows.
Yes, in my environment, there is nothing entered into tickets that is required to be kept hidden from the group that I gave the permissions to. However, because I have several groups using the same Servicedesk and I don't want certain groups to see certain data, I am using separate process views and dynamic forms. So if you are in group a, you have rights to this feeder form and you are directed to this process view. If you are part of group b, you have rights to a different feeder and are forced into a different process view. If you are group c, you will use the group b feeder, but using dynamic/hidden data as described in an aritcle on workflowswat, you will see some fields that group b cannot see, but you will not see some fields that group b can see. I am also working on custom web parts, but don't like the way the iframe lays out so far.
Wish I could have been more help.
rdvanorman are you in Houston? If so, I am as well. I would be curious if I have possibly met you before at the user group. I was Administration Director for the Houston Endpoint Managent User Group with Renato and Tahir for a short period prior to becoming a partner. I am alway looking to meet local admins when I can.
From what I hear from support personnel, they are locking the Service Desk down and enabling a "project store" to allow snapin apps to work with Service Desk. I have implemented several Service Desks and none have ever been the same. In my opinion, it is difficult to agree with the 'one size fits all' Service Desk. This has been somewhat of a challenge with customers. To a degree I cannot blame you for looking the other way.
I have tried the workaround you mentioned in workflow. Unfortunately,it will not work with customers wanting to limit confidential data.
I went into the IncidentManagement Workflow -> Model: Initial Diagnosis -> Initial Diagnosis component and go to the Event Configuration tab and open the Start Process model, and after the Add Task Assignment component, I added an Add Process Permissions component and configured it for the group. Adding it after the Task Assignment component gives the group permissions to every incident created regardless of whether the assignment is to a group, individual, permission, etc...
Hope when 7.5 comes out that they give us freedom to put these types of permissions in without making everyone an admin. We will probably be looking for a different product in the near future if 7.5 is as locked down as it sounds, as the current product does not meet any of our needs without heavy customization.
Yes.. we have that issue and also some custom groups. Out of the box the default groups have specific permissions. If I remember right you have to go in the workflows and add custom groups in order for them to have the same rights.