This wasn't going to be a "Tip" post but it's Monday night as I write this, so it's now becoming this week's #TipTuesday. Funny how deadlines work! :)

Late last week, I was working on some upgrade tasks as my firm was going through an upgrade from Dynamics GP 2013 to GP 2016. One of the tasks on my checklist was to review the Unassigned Security Report for new features and update security roles as needed. However, I ran into an issue.

Overview of the report

This report can be found under Security reports (Administration > Reports > System > Security) and it shows all resources that are not assigned to any tasks, hence, "Unassigned". They could be windows, reports, files, or any type of security resource that is assignable to a task.

It's not a report I use every day by any stretch but it is a report I rely on with every upgrade I've ever worked on. I run the report from the old version and the new version. The differences in the report are what's new in the new version of GP. If security is kept up to date, I may not have anything on an unassigned security report until an upgrade, but everyone probably has a different opinion on this. I like to ensure most things are in relevant tasks even if they aren't assigned to anyone in particular. There are some tasks I don't think regular users need like "clear data", however, I would prefer to have a task that contains those things so that this report is usable in an upgrade.

I'll digress for a moment to discuss the out-of-the-box POWERUSER role vs. the increasingly common "SUPERUSER" role advocated by many GP consultants out there.

POWERUSER is a default role that has security to everything in Dynamics GP, but the significant downside is it's invisible in all security reports. Any report generated regarding who has access to what in Dynamics GP will not include users in the POWERUSER role. That's intentional, and that can be a problem.

On the Security Role Setup for POWERUSER, it has no tasks assigned to it, it cannot be deleted and nothing can be assigned to it. It's effectively hard-coded access to anything on GP. Nothing is explicitly granted, so it's invisible.

Security Role Setup for the POWERUSER role.

Introducing SUPERUSER roles

I believe Mark Polino was the first one to be an advocate for a SUPERUSER role in GP. His position is if organizations really want a POWERUSER type of role, create one explicitly, then at least users with that role appear on every security report and there's no second list of users you need to remember that have access to everything because of one role.

The premise of the SUPERUSER role is it is explicitly granting security to every resource in Dynamics GP and then any users assigned to that role will be visible on any security reports.

What does this have to do with Unassigned Security reports?

The same reasons that keep POWERUSER off of regular security "access" reports also apply to the Unassigned Security report. Technically, since POWERUSER has everything, there is no such thing as any unassigned resources. However, the report works because POWERUSER is ignored. It shows resources not explicitly granted to any task.

However…

This brings me to my issue, that the SUPERUSER role effectively eliminates the usefulness of the Unassigned Security report. If I have a role with explicitly granted secuirty to everything in Dynamics GP, the report will literally be blank. There is no longer "unassigned security" because at least one role has everything assigned to it.

It's not a surprise of course but not something that one would think right away.

So… back to my upgrade. I hadn't created SUPERUSER manually but one of the features of David Musgrave's GP Power Tools is his product will auto-create (or update) a SUPERUSER role whenever the System Resources table is updated (SY09400). I didn't know this until I ran the Unassigned Security report and found it was blank. Then I noticed I had a new SUPERUSER role that I hadn't created myself. Hmm.

In the grand scheme, this problem is minor, however, there is then no easy way to identify what new objects exist to grant security to "normal" users during an upgrade. Since I raised this issue, David has updated the latest build of GPPT to exclude SUPERUSER from his unassigned security resource queries.

My Recommendation

In my case, since I haven't updated to that build yet and am in Test Upgrade mode, I deleted the SUPERUSER task to run the Unassigned Security report as originally intended. In a test environment, I'm not worried about having perfect security with a SUPERUSER role intact. I am interested in what's new so I can properly assign new objects to tasks and roles though.

Once I have that list, I can re-trigger an action that will auto-create the SUPERUSER role or simply wait until the live upgrade for it to be re-created. By then I will have a complete list of what new objects need assigning to what tasks and be ready to go at Go Live.

In the long run, SUPERUSER is better than POWERUSER, and this is likely the only situation I'll ever run across where SUPERUSER is a problem!