Locks Everywhere

I recently had a conversation with a client that inspired me to write this post.  The conversation was billed as needing to understand FDM security.  The client was trying to determine how to prevent users from loading through an FDM location, category and time period.  I know what you’re likely thinking, 1. this isn’t security and 2. how are you going to create an entire post around the “Lock Current Point of View” function in FDM.  Stick with me, I promise it’s more than that.

So I start with a bit of education.  I explain there are 3 or 4 types of locks available in the application:

Function Use
Lock Current POV Prevent data from being processed through a single location, period and category combination
Lock all Locations for Current Period & Category Prevent data from being processed through any location for a given period and category combination
Point of View Mode Lock Prevent users from changing the period or category in the point of view
Application Lock Prevent non administrative users from logging into the application

Naturally my first suggestion is a simple Lock All Locations.  All set right?  Not quite.  They did not want the overhead associated with locking and unlocking Locations.  As the conversation proceeds, I learn that they are instead using the Application Lock to achieve this functionality.  Well now I’m intrigued because that doesn’t sound quite right to me.

I proceed to share some knowledge about the Application Lock.  The Application Lock functionality allows an administrator to prevent users from logging into the application.  This is especially useful when performing migrations or application maintenance such as script updates.



When the application is “Locked” non administrative users are unable to login and receive an administrator defined message indicating that the application is locked.

Well this approach which they had been using no longer works because all the users have been provisioned as administrators in the upgraded application.

My thought at this point is: ok, you don’t want to lock the POV and the application lock won’t actually provide you the ability to lock users out of a POV.  So we can manage data processing using a bit of technology and a bit of business process.  The next lock functionality I highlighted was the point-of-view (POV) mode lock.  I explained that when the POV Mode Lock is enabled, non-administrative users are unable to change the FDM category or period.





And you guessed it, this won’t give them what they need either.  Why not, you ask.  Well there are 2 “types” of users in this particular FDM application.  Those that can change the POV to process data through multiple categories and those that are restricted to the current time period and category as defined by the administrator.  Well POV Mode Lock is a global setting so enabling it or disabling it applies to all users so this is out.

Application Lock, POV Mode Lock, Lock Current POV, Lock All Locations – none of these will address the client’s needs.  Come on Tony, I’ve been reading this blog long enough to know that you rarely tap out on a problem.  Well folks, you’re right.  Before we get there, let’s address one item.  Don’t use the application lock for this problem.  It does not provide the intended locking.  Once the application is unlocked, there is nothing to prevent an end-user from changing the point-of-view since the POV Mode lock is disabled.

To this problem, I have 2 potential solutions.  First, create a custom script that will lock a defined set of locations, category and period combinations.  This would be similar to the Lock All Locations functionality but more targeted to specific points-of-view.  If this does not address the need then another solution could be to create an event script and “classes/types” of users.  One class/type would be the users that cannot change the POV while the other is the users that can.  The POV Mode Lock would be disabled but the event script would determine if the user is in a class which can change the POV.  When changing the POV, if the user is not part of the class that is allowed to change the POV then the POV would be reset and the user would be alerted.

So at the end of the day, I guess this was somewhat of a conversation about security and a reminder that even the things that seem like they should be simple can often end up being a bit complex.  The life of a consultant…

So let me throw it back to you, how would you handle this requirement?

This entry was posted in Extending FDM, Out of the Box Functionality. Bookmark the permalink.

Leave a Reply