[AccessD] Table driven security was [allow edit false]

Jim,

I understand the workarounds, I am just bitching for no apparent reason.  ;)

The objective of my PLSS is to allow a security administrator to set up security for an Access 
Application in a table driven fashion.  The whole point is to minimize the "code around" solutions. 
  My previous system used the "code around" system and it was almost impossible to report and 
understand the security.  When the client asks "what items in the application have security 
applied", how do you answer that?  This happens to me, and it ain't cool!!

"Uh... I'll get back to you on that" and then you go in and start searching for all of your code and 
writing down the forms and controls that you are doing this kind of stuff to.  I had to do that and 
it sucked.  When the client said "we need form Groups X, Y and Z to be able to do this in form A, I 
had to go into form A and start writing code.

ICK!

Now they come back and say.. "oh yea, and group W needs to be able to do this in form A" so I go 
back in to form a and look at what I have already done, then start writing code to do that.

ICK!

I did that!  ICK!

When the client asks about security, I want to say "open rptSecurity" and have the client see each 
and every object that has security applied.  I want to allow the Security Administrator be able to 
open a security wizard and see the current security for every form, and be able to modify that 
security using the wizard.  To be able to see the controls on the form and what security is applied 
to those controls, and be able to modify that security from the wizard.  And when they are done, to 
be able to report on that security.

That is the goal of C2DbPLSS, and it is starting to work! Form security is working, the wizard 
allows you to see and modify all form level security.  Reporting is trivial because the security 
information is in tables.  I am working on the control security now.

The bottom line is that "reality is" and we have to deal with that.  I do not control what happens 
when AllowEdits is set to false, and it is not my responsibility to make an application behave in 
the way we would expect it to behave when that property is set.

The way it does work make application of security, and in particular AllowEdit security, tough to 
apply.  AllowEdit security is probably the kind most needed, and to have it crippled like this is 
irritating.

But Reality Is and all we can do is acknowledge and understand the implications and get on with 
programming around the limitations.

 >You could also use the controls tag property as a flag as to whether or not you wanted to 
lock/unlock the control.

And I virtually never use the tag property, even in my own applications and I NEVER use the tag 
property in applications written by others.  The reason is simple - collisions with other developers 
usage of that property.

It is possible to write form properties - vba variables in the header and property get / let / set 
and then read the data out of tables.  More work but infinitely extendable, and no collisions.  Or 
classes to do the same thing.

John W. Colby
www.ColbyConsulting.com

On 9/10/2010 8:43 AM, Jim Dettman wrote:
> John,
>
>    Yeah, pretty silly.  The way I've always handled this to put any "control"
> type controls that I always want active in the header of the form.
> Everything else goes in the detail section.  I have a routine (see below)
> that loops through all the controls and if they are in the detail section
> and enabled, I set their lock property.
>
>    You could also use the controls tag property as a flag as to whether or
> not you wanted to lock/unlock the control.
>
> Jim.