[AccessD] A2K - setting a form invisible on open

John,

I guess my angle is cost vs. benefit. It seems to me that the effort
required to implement this feature in _precisely_ this way outweighs the
value it gives to your target developer audience, and their users.

I can only speak for myself, but I suspect most developers would be OK with
a slight redefinition: Open = Open permission AND View permission for that
form.

Maybe you could add a LWS form class called 'Hidden', which could only be
opened in code with Admin permissions, but whose visibility is not
manipulated by LWS.

Or, you could turn the problem on its side, and ask whether View permissions
are really necessary: maybe if you can Open the form, it has whatever
visibility is granted by the developer. If you can't open it, visibility
doesn't matter. If this is acceptable, it would simplify using, coding and
supporting the app.

One of the hardest tasks in development is determining the boundaries of
your project. It has to do some needed thing in a slick enough way to
attract customers. But, it can't be so intrusive that it needlessly hinders,
either. Getting that balance is tough. That's why its good to get input from
others, so you can better determine where to make compromises, and where to
stand firm.

-Ken


-----Original Message-----
From: Gustav Brock [mailto:gustav at cactus.dk]
Sent: Tuesday, November 11, 2003 10:54 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2K - setting a form invisible on open


Hi John

Well, we must live in different worlds. Most of our users are in
runtime environments and even those with full versions of Access
don't fool around with the apps - and they indeed "don't just open
forms" - they use the UI.

If wild users is the developer's concern, a LWS tool is not an option
- his/hers only way to go is full Access security - if not applied,
these users will, of course, find your LWS tables.

Also, I've used the table wizard once - and that was it. The only
wizards I've found a use for are that for creating a simple report and
that for creating a group box. The Access switch board and the table
structure behind it is terrible; I've found it just as quick to design
a main form for that purpose and a single table or two holding the
user level security.

I'm not saying there isn't a need for a LWS system, just that it will
not fully block the scenarios you draw which means you could pay less
attention to those extremes. How many users know a form can be hidden?
Not to say how to locate a hidden form and unhide it? Why should they?
Most users have work to do.

/gustav


> 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".