Blog

Sunday, March 16, 2014
checking user roles in AX 2012
It's been a while since I've posted anything related to Dynamics AX / X++, so I thought I'd write up something I stumbled across recently. I had created a custom form, with a number of buttons on it. Two of the buttons needed to be available only to users in a certain role.

Well, first, I should point out that this can be done without any code. See here and here for information on that. And there are good reasons to do it this way, in many cases.

But there are also some good reasons to do this in code. It allows you to document what you're doing and why, and it gives you more flexibility than just doing it through properties in the AOT. In my case, the business rules around this didn't really fit into the permissions available in the AOT (Read, Update, Create, and Delete), so while I could have picked one of those and used it, it wouldn't have accurately reflected the actual use case.

So I first wanted to find a method in X++ that would tell me if a given user was in a given role. I'm familiar with Roles.IsUserInRole from the .NET Framework, and have used it frequently in the context of ASP.NET sites using custom membership providers. So I looked for something similar in AX. That led me to the SysUserManagement Class.

I wound up writing a utility method that made use of this class:
It worked fine on my VM, when logged in under my own ID. But, after deployment, it quickly became apparent that X++ code running under a normal user account (without SYSADMIN rights) can't call methods in the SysUserManagement class. Now, there's nothing I can see in the documentation that indicates that, but I should of course have tested my code under a normal user account.

So I rewrote my code to access the appropriate role-related tables directly, and it turns out that a normal user can do that, no problem:
So I guess the lesson here is to always test your code under a normal user account, and not to assume that the MSDN page for a given AX class will tell you everything you need to know about that class.

And, as with a lot of stuff in AX, I have a feeling that I'm *still* doing this "the wrong way", even though my code works and is fairly simple. I'm guessing that, a year from now, I'll have figured out that there's a better way to do this.

Labels: ,

posted by Andy H. 10:54 AM
0 comments

Comments: Post a Comment


This page is powered by Blogger. Isn't yours?
© 2011 Andrew Huey