Tracking down a GP 10 security task that is granting unwanted access to a window

I don't spend a whole lot of time in GP 10 security. I appreciate the design of the new security model, but I find configuring the security roles and tasks tedious, so I'm thankful I don't have to deal with it often.

GP 2010 does have some enhancements that will make configuring GP security easier, but for those still on GP 10, you are limited in your ability to research certain security settings.

I recently fielded a question about GP 10 security where the user was looking to remove access to specific SmartLists, but he was unable to determine which security Task in his Role was granting the access. He had unchecked all of the tasks that seemed obvious, but the SmartList was still visible to the user.

After poking around, I saw that the SmartLists were not assigned via separate, discrete Tasks--they were assigned to Tasks that provided access to other types of objects.

Below is one approach to figure out which security Tasks grant access to specific GP objects. In my example, I'm trying to figure out which security Tasks provide access to the Accounts and Multidimensional Analysis SmartLists, but you can use the same technique to track down almost any other GP object.

There may be other ways to figure this out, but this is what I came up with, which was quick and simple.

1. Create a new empty security Task (I called mine "1TEST")
2. Assign it to category Financial
3. For Product, select SmartList
4. For Type, select SmartList Objects
5. For Series, select SmartList Objects
6. Check only the Accounts and Multidimensional Analysis checkboxes
7. Save the Task

Run this SQL statement against the "Security Assignment Task Operations" table:

SELECT * FROM DYNAMICS..SY10700 WHERE SECURITYTASKID = '1TEST'

This will list the security IDs for those specific SmartLists. In my TWO database, they are 1 (Accounts) and 14 (Multidimensional), with a security resource type = 1000 (presumably SmartLists).

Now, query the security task table again to see what other tasks are granting access to those two SmartLists:

SELECT * FROM DYNAMICS..SY10700 WHERE SECRESTYPE = 1000 AND SECURITYID IN (1, 14)

In my TWO database, that shows me that the following Tasks are providing access to those SmartLists:

1. CARD_0101 (Accounts)
2. CARD_0102 (Accounts and Multidimensional)
3. INQ_FIN_001 (Accounts)
4. INQ_FIN_002 (Accounts and Multidimensional)


This quicky tells me all of the Tasks that provide access to those SmartLists, so now I can go back to my Role and determine how I want to remove access.

I could uncheck all four of the Tasks, which will do the trick, but it may also remove access to windows that the user should be able to access.

Another approach would be to modify those Tasks to remove access to the two SmartLists. This would also work, but any other users that rely on those Tasks to view the Accounts and Multidimensional SmartLists would lose access as well. In that case you can create a new tasks that gives access to those SmartLists, and add that task to a new or existing role for users that need access.

Clear as mud?