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 is 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
You would find this report under the 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, 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, you may not have anything on an unassigned security report until you upgrade, but everyone probably has a different opinion on this. Personally, 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.
Sidebar: POWERUSER vs. SUPERUSER
I’ll digress 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 you generate regarding who has access to what in Dynamics GP will not include users in the POWERUSER role. That’s intentional, and that’s a problem.
Take a look at your Security Role Setup and you’ll see POWERUSER has no tasks assigned to it, you cannot delete it, and you can’t assign or unassign anything to it. It’s effectively hard-coded access to anything on GP. Nothing is explicitly granted, so it’s invisible.
Introducing SUPERUSER roles
I believe Mark Polino was the first one to really be an advocate for a SUPERUSER role in GP. His position is if you 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 have access to everything because of one role.
This blog post outlines how to actually create a SUPERUSER role manually (link removed, no longer valid) inside Dynamics GP and it’s a great idea. It’s explicitly granting security to every resource in Dynamics GP and then any users assigned to that role will be visible on any and all 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’s showing 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 you have a role with explicitly granted secuirty to everything in Dynamics GP, the report will literally be blank. There is no longer “unassigned security”.
It’s not a surprise of course but not something that one would think right away unless you went to use it.
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 super easy way to identify what new objects exist to grant security to your “normal” users for during an upgrade. Since I raised this issue, David has updated the latest build of GPPT to exclude SUPERUSER from his own unassigned security resources 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 in order 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 actually a problem!