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

I am handling field level data entry using table driven control security.  It is not uncommon to 
have specific controls that are not visible at all, or visible but locked to specific groups.  I 
handle that already (or will when it is finished).  Each control on a form may have Visible, Locked 
and enabled properties manipulated at form load.

John W. Colby
www.ColbyConsulting.com

On 9/10/2010 11:30 AM, Jim Dettman wrote:
>
> <<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.