I have attached a zip file that contains the complete sample application solution for Visual Studio 2008 using C#. This was created using Strataframe version 1.7.0.2



I did not change any of the default code that was generated by the Strataframe template. I only added code for the "click" event of the button that I added to the form that was created by the template.



You should be able to unzip this file structure and then build, compile and run the application in the normal default debug mode of Visual Studio.



The zip file is named SecurityTest.zip

Trent,

Adding the "Security Basics" patch code line did solve the problem.  I don't know what data for the application that you are referring to ... The use of the "integrated" Administrator and "integrated" Security Maintenance users should not require any "security" data to be set up for them ... There is no reference to them when you populate the security tables with user / role / permission / restriction information.

And I did verfify that the "security key" information matches ...

I think that maybe you still do not understand my problem ....  With the sample application that I posted, the integrated Administrator user works just fine ... no problems at all .... can access the Security Forms as expected .... BUT without adding the patch code line suggested in the previous post above,  the integrated Security Maintenance user can not access the Security Forms ....  You get an "Access Denied" message when you try to show the Security Forms dialog ....  After adding the patch code line, and not changing anything else ... the Security Maintenance user is able to access the Security Forms dialog as described in the documentation and samples ... just like the Administrator user can do before adding the patch code for the Security Maintenance user ...

There is something in the Strataframe code that will not let the integrated Security Maintenance User have access to the Security Forms without adding the patch code to an application.  This patch code has worked on every application that I have tested so far ....  WITHOUT the patch code ONLY the Administrator user can access the Security Forms ... BUT with the patch code BOTH integrated users can access the Security Forms ....

If you DO NOT add the patch code and use the integrated Administrator user to add Application Admins to the security table and give them "Administrative" rights when you set up the Application Admins, they ALSO can access the Security Forms without any problems ....  the only problem is with the integrated Security Maintenance user if you do not add the patch code suggested in the previous post ...

Does this information help explain the problem any better?

It does to me

Edhy Rijo

With very helpful assistance from Greg McGuffey, I have followed the flow of the code related to how the integrated Security Maintenance User is granted default permissions to the objects within a project.

Here is the short (and hopefully simplified) version of what I discovered with Greg's assistance:

1) In the Strataframe source code,  the "SecurityMaintenanceKeyPrefix" property is given a default value of "Security_"

2) In the Strataframe source code, the "Security Dialog" form is given a default "Security Key" of "Security Editor"

3) The integrated Maintenance Security User is granted security to objects based on the "SecurityMaintenanceKeyPrefix" value ... in this case "Security_"

This means when the integrated Maintenance Security User is logged into your application, any objects which are defined with a "Security Key" property value that STARTS WITH "Security_"  will be issued the "GRANT" permission for that object and allow the integrated Maintenance Security User access to that object

This is where the problem is created .... everything matches in the 2 character text strings through the word "Security" but the next text character is causing the Strataframe Security System to issue the "DENY" permission for the object (which is the Security Dialog form) because the prefix value is looking for an "_" (underscore character) as the next text character in the evaluation of the Security Key value for the object BUT the object (Security Dialog form) has a " " (space character) as the next text character and this DOES NOT MATCH !!!!!! 

Therefore, the integrated Security Maintenance User is denied access because of the mismatch between the space character and the underscore character.  Greg's patch code suggestion of adding a code line in the program.cs file to "redefine" the "SecurityMaintenanceKeyPrefix" to be "Security " ... works because this makes the " " (space character) after the word "Security" match in the prefix value and the object Security Key value.  As Greg also suggested, I have tested changing the "SecurityMaintenanceKeyPrefix" value to just "Securty" and this works just fine also BECAUSE the Strataframe Security System is matching the text characters from the "SecurityMaintenanceKeyPrefix" and the object "Security Key" for the length of the "SecurityMaintenanceKeyPrefix" text string.

A future fix for the Strataframe Source Code would be to change the default value for the "SecurityMainenanceKeyPrefix" or change the default value for the "Security Key" for the Security Dialog form  SO THAT they will both have the same "Starting" characters for the length of the "SecurityMaintenanceKeyPrefix" text string.

Trent, can this be done in a future release version ?????

A BIG Thanks goes to Greg McGuffey for helping me work through and understand this problem and the required solution.