Dynamics GP system administrators and Microsoft SQL Server DBAs often ask, "Why can't I setup users if I am a member of the POWERUSER role in Dynamics GP?". The question can sometimes be paraphrased as "Why the SQL Server system administrator (sa) user is the only one that can setup users?". The answer is simple: the Dynamics GP POWERUSER role is application specific, while the SQL Server sysadmin role is database specific.

Since sa is a member of both the POWERUSER role in Dynamics GP and the sysadmin role in SQL Server, it can perform all maintenance operations of users in Dynamics GP, along with the setup of additional users. This allows the sa user login, in turn, to create the necessary logins in SQL Server. This is good if you are a DBA, but what happens when you are out and more users need to…

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…

User Copy

Module: System

Why this feature is cool!

· Provides the ability to quickly copy all security access from one user to another

· Copies all security operations, tasks, roles and company…

The first time that you log in to Microsoft Dynamics GP 9.0, you can select to have default information that…

When you try to give a user access to a database you get the above message. To resolve this you need to have…

It's almost Thanksgiving and Jivtesh is talking roles in GP 10. No, not dinner rolls, quit…

For as good as the keynotes were, there's still some confusion around roles based security. So I went to the session and I have to say that I was a little disappointed. This is a sore area and while version 10 makes some big strides, the Q&A afterwards left me with more questions than answers.

What I do know is:

It's Role Based
There are operations (lowest level, a window, report, etc.) for example an AP Window
that are grouped into tasks like processing AP

Which are grouped into a role like an AP clerk.

How is this different from classes? Well the third level makes huge difference. The task is essentially a function. So I can build security functions (enter AP, Cut AP checks, Post AP, etc) that are pretty independent of the user and then as the role changes, I can give and take away tasks without…

For as good as the keynotes were, there's still some confusion around roles based security. So I went to the session and I have to say that I was a little disappointed. This is a sore area and while version 10 makes some big strides, the Q&A afterwards left me with more questions than answers.

What I do know is:

It's Role Based
There are operations (lowest level, a window, report, etc.) for example an AP Window
that are grouped into tasks like processing AP

Which are grouped into a role like an AP clerk.

How is this different from classes? Well the third level makes huge difference. The task is essentially a function. So I can build security functions (enter AP, Cut AP checks, Post AP, etc) that are pretty independent of the user and then as the role changes, I can give and take away tasks without…