+7K2.net 2003 Workspace uses the Active Directory (AD) to provide hierarchical access to users' worklists.
To access the worklists of the members you manage, you will need to ensure that the AD has registered you as the manager of that OU/Group. To do that, do the following (assuming you have admin rights to manage AD):
1. Start the AD and navigate to the OU/Group, right-mouse click to select Properties.
2. Click on the tab, "Managed by" and add yourself as the Manager (if your are not already the manager of the OU/Group)
3. Save the settings
After that is done, you may return to your K2 Worklist to see that the names of all sub-ordinate members of the OU/Group you manage are displayed under your name. These links enable you, the manager of the OU/Group, to access the worklist of each OU/Group member's worklist.
To access the worklists of the members you manage, you will need to ensure that the AD has registered you as the manager of that OU/Group. To do that, do the following (assuming you have admin rights to manage AD):
1. Start the AD and navigate to the OU/Group, right-mouse click to select Properties.
2. Click on the tab, "Managed by" and add yourself as the Manager (if your are not already the manager of the OU/Group)
3. Save the settings
After that is done, you may return to your K2 Worklist to see that the names of all sub-ordinate members of the OU/Group you manage are displayed under your name. These links enable you, the manager of the OU/Group, to access the worklist of each OU/Group member's worklist.
+4I tried following the directions you gave and I still can't see the subordinate users worklists in the manager's workspace.
+4I found out that if I set the manager up from a users's point of view - by going to active directory users and computers, then choosing the subordinate and then setting the manager property in the orgnaization tab - that seems to have worked.
I think that k2 reads this property - and this seems to be set either from a users standpoint or by organizational unit, because if I set it at the group level (as described in the beginning of this thread) the manged by property is not populated. Doing it by OU does populate that field. This would make sense - since a user can only be in one OU but could be in many groups. Therefore when fetching the worklist for a mnager - it would have to evaluate every group in order to determine if that user is a mnager of any of the groups.
I hope this saves someone the time I spent messing around with this
I think that k2 reads this property - and this seems to be set either from a users standpoint or by organizational unit, because if I set it at the group level (as described in the beginning of this thread) the manged by property is not populated. Doing it by OU does populate that field. This would make sense - since a user can only be in one OU but could be in many groups. Therefore when fetching the worklist for a mnager - it would have to evaluate every group in order to determine if that user is a mnager of any of the groups.
I hope this saves someone the time I spent messing around with this
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.