Drew Wutka
DWUTKA at marlow.com
Wed Nov 12 10:10:18 CST 2003
JC. I may have missed it, but did you try the repaint/doevents suggestion?
Drew
-----Original Message-----
From: John W. Colby [mailto:jcolby at colbyconsulting.com]
Sent: Wednesday, November 12, 2003 8:53 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] A2K - setting a form invisible on open
What you're missing is that THIS IS A WIZARD FOR YOU!!!
I have no clue what YOU are doing so I have to desing it as if YOU don't
have a clue.
John W. Colby
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte
Foust
Sent: Tuesday, November 11, 2003 11:16 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] A2K - setting a form invisible on open
Am I missing something, John? If you're using a forms class, wouldn't
there be a test in the Form_Open event of the class to see whether the
user is allowed to view the form? Or are you talking about users
managing to find their way into forms already opened hidden?
Charlotte Foust
-----Original Message-----
From: John Colby [mailto:jcolby at colbyconsulting.com]
Sent: Tuesday, November 11, 2003 7:52 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] A2K - setting a form invisible on open
Gustav,
>I mean - forms don't just open
Of course forms "just open". What do you think the switchboard does?
It "just opens" forms. And plenty of developers use the switchboard.
>and users don't unhide hidden forms
Of course users unhide forms. Users poke and pry, and go where they
aren't supposed to, and find all the chinks in your armor. If it's not
supposed to be done, and you have locked that sucker down tight, a user
WILL get in there!
>he/she would need to either make the button not visible or not enabled
>or
pop up a message telling that the user has been revoked rights to view
the details; this I guess would be beyond the goal of your LWS tool.
No, in fact that is exactly the goal of my tool. It allows you to
create up to 31 groups and unlimited users. You then add users to
groups, ala Windows or SQL Server. You then tell LWS "These groups can
SEE these forms". "These groups can see this control on this form".
etc.
The flip side of this is that any groups NOT allowed to SEE those forms,
by definition CAN'T SEE those forms. And it is the job of LWS to
guarantee that those users CAN'T see forms they are not supposed to see.
Thus my email - how do I GUARANTEE that a form that the user is not
supposed to see remains invisible?
The point here is that every one who has responded so far has simply
taken the point of view that "the developer will guarantee" or "users
won't" or "of course the developer will get rid of menus" etc.
We all know that NONE of these statements are true. Developers
consistently, every day, fail to guarantee... Users, every day,
consistently break into places where they aren't supposed to be, often
quite by accident. And Of course, developers consistently, year after
year fail to remove menus. In fact clients consistently, year after
year DEMAND that menus remain. It is not realistic to start from the
perfect world and assume none of these things happen.
I have a simple question. How many of us know how to build a table.
The first thing all of you will say (waving hand in the air shouting
frantically) is "I do, I do". But in fact I don't have a clue how to
build a table. Or more correctly I can figure it out using DAO, and I
can figure it out using SQL but what do I do under normal circumstances?
Use a WIZARD. The wizard knows how to build a table, I know how to use a
wizard to build a table. Same with queries.
I am attempting to design a system (a wizard) that a developer can use
to set up the type of security we are discussing here, which I call
"presentation security". Light Weight Security allows the developer (or
even the client) to set up the groups and users. Once these two tables
are initialized, there is a "wizard" that allows the developer to select
forms and then assign groups that can Open/See/Edit/Delete/AddRec etc.
Whatever the developer decides is stored in a pair of tables (forms and
controls).
Notice that all of these things (except open) are nothing more than
properties of the form. LWS is attempting to manipulate form properties
based upon information stored in tables.
The wizard will allow the developer to select a form, see all of the
controls on the form, and select controls that you wish to lock down
such that only specific groups can See/Enter/Edit.
That is LWS. The group / user login stuff is working. The FORM
security is working (minus a few inconsistencies in being able to hide
the forms). The control security is not finished yet. My post to this
group was an attempt to figure out how to allow LWS to consistently and
reliably control the VISIBILITY of a form. Access does not make it
easy, but I have had a couple of good suggestions that will help me
solve this problem.
John W. Colby
www.colbyconsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
Sent: Tuesday, November 11, 2003 4:09 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2K - setting a form invisible on open
Hi John
I think Ken has a point here and that you maybe are overcomplicating the
task. I mean - forms don't just open, and users don't unhide hidden
forms; how should they be able to do that when the developer has
designed menus and toolbars for his/her app?
Also, applying any form of security, light weight or not, the developer
will have to walk through the app from a to z and arrange for
modification of menus, buttons, labels ("Double click her to view
details") etc. If a button is labelled "Show details" on a form and it
should be disabled for certain users, he/she would need to either make
the button not visible or not enabled or pop up a message telling that
the user has been revoked rights to view the details; this I guess would
be beyond the goal of your LWS tool. Leaving the button as it is and the
user presses it and the details form just opens hidden is bad UI design
as the user has no chance for knowing what is going on other than "it
doesn't work".
/gustav
> Ken,
> I am writing a security utility aimed at other developers. It is
> designed to allow YOU (and me as a developer) to manage the
> presentation security
of
> a database front end. IOW, what forms can a user / group open? View?
Add
> records to? Delete records in? Edit records in? Etc.
> As you can see, I am not necessarily "in control of" the target FE at
design
> time since the FE is YOURS. Why would you want to open a form not
visible?
> Perhaps the form is a filter form that you use to feed values to a
> query. Perhaps the form has a timer ticking that performs some
> process.
Perhaps...
> uh... I have no damned idea what else you might decide to do with a
> form that is open but that a selected group or groups of users are not
> allowed
to
> see. I know that I personally use a hidden form to force a cleanup of
> my framework when the database closes. Since a form cannot close
> without
it's
> OnClose firing, I use that to run a Terminate() function that closes
> everything gracefully. So not matter how the db closes, my term()
function
> runs.
> I cannot allow the users to unhide that since it is a background
processing
> form and they have no business there.
> In the end though, the answer is I don't know why any given developer
> is going to want to open a form that users can't see, I simply know
> that it happens and I need to provide the developer with a means of
> enforcing this security.
---
> 1. It escapes me why you would even want to manage an open, invisible
form.
> If the user can't view it, then by far the simplist thing to do is not
open
> it. Is there some other issue driving this need that you haven't
elaborated
> on?
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com