I am wrestling bears at three different implementation stages, and have not been writing any blogs lately. Fortunately, my coworkers are covering for me again. 🙂 Jesse Higdon recently corrected an issue one of my clients was experiencing: They could un-filter employees and see everyone. Jesse quickly figured the fix and was kind enough to blog it for us. Thanks, Jesse! Hope to see you blogging again soon!

Happy DAXing!

From Jesse:

Gotcha, Microsoft!

Recently I was given an interesting task. A client had an issue that they deemed was a security issue.

The form is located at Human resources > Inquiries > Time and attendance > Attendance. The user is prompted to select a calculation group from a dropdown. A manager selects their own calculation group and they get to see a form with attendance information for their own employees. The issue is that once they clicked the Attendance button, after closing it either with the X or the Close button, upon returning to the list of employees it would no longer be filtered and they would be able to see and select and modify data for any employee in the system.

I tracked the issue to a bug in some stock Microsoft code.

The form is JmgEmplSignedIn. There is a method on this form called retriveAttandenceDataForCalcGroup(). It takes a single argument: JmgCalcGroupId _calcGroupId. The calc group selected on the dialog gets passed to this method because this is the method that actually filters the data on the form.

This gets called when the form is opened, but it gets called again when the user closes that second form. The bug is that when the user closes the second form, the method is called without specifying a _calcGroupId. This means that the filter that was originally applied is effectively removed and the user will end up seeing all employees. Since there’s no data level security behind this form, there’s nothing to stop a manager from messing with another manager’s employees as long as he can see them in the grid.

The solution to this isn’t the most elegant code I’ve ever written, but it contains the solution inside of one method and keeps it short and sweet.

I check if _calcGroupId is blank, and if it is then I simply assign it the value of jmgGroupCalcId. When the dialog gets the calc group id from the user, it stores this into a class variable called jmgGroupCalcId which doesn’t get overwritten by a null string when the user returns from the second form.

I could also have made a change like this:

public void retriveAttandenceDataForCalcGroup(JmgGroupCalcId _calcGroupId = jmgGroupCalcId)

In retrospect, that could be a more elegant solution, but it’s not one that I have tested, so use it at your own risk. The solution I show in the screenshot has definitely been tested and confirmed to work by myself and the client.

Never thought so early in my Dynamics AX career I’d manage to find and fix a bug in stock Microsoft code, but that just goes to show that even Microsoft developers are still human.