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

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

  Oh I would not say there is no reason; Access is certainly not the most
developer friendly tool around.

  But I guess I don't consider the locking/un-locking of controls a code a
round solution.  I think you'll find that once you go down that table driven
security road, your going to need that level of control no matter what,
especially if you want to carry it down to the field level.

  Right now, I have table driven security down to the object level and could
extend it down further if need be.  But I've never bothered because I've
never found the need to.  From a functional standpoint, once someone's in a
form they usually need all the basic CRUD operations.

  But with having the unlock/locking of controls already in place and all
the CRUD functions controlled with my own buttons, I could extend the
security down quickly enough if I had to.   I could even go down to the
field level if I needed to as I do that with setting user preferences
already.

  But if you want to do table driven security, I think you'll find there's
no easy way out<g>.

Jim.

   

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, September 10, 2010 9:46 AM
To: Access Developers discussion and problem solving
Subject: [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.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com