FW: What's the best way... -Reply

[Lindley HILL]

We do something similar with a separate set of security tables to check users against allowable functions rather than using the inbuilt PH security options.

Additionally we have a number of screens which we use for both update and enquiry, based on the access the user has. To avoid the user entering any information without reason we have an input procedure for each field for which data can be entered which calls a common internal procedure to check the security and issue an error if appropriate. It is a bit of additional coding, but a neater user interface than waiting until the preupdate, or even the edit procedure for that matter. 

Lindley Hill
NSW Health Dept
Sydney Australia

>>> rkessler <rich@thestewart.org> 19/March/1999 02:54am >>>
FWIW,

We have created a small database to associate user-names with screen names.
Each screen includes a USE file which checks the logonid/username against
allowed access in the list.  Before a subscreen is called, the name of the
screen to access is set and the USE procedure is called.  If the person
has no access, they get an "Access Denied" error message.

[[actually there is a list for 'only users' (allow access) and 'all except'
(deny access to others). this gets confusing quickly. Fortunately, we don't have
to modify user access often, and have a qtp to 'copy' sets of access
lists from one user to another.]]

We have modified this scheme to include a screen called NOUPDATE
then call the USE file/procedure in the PREUPDATE procedure and
blow out of the update if the person is a NOUPDATE user. 
The limitation we have seen with this is that a person is NOUPDATE
everywhere it is used. We have not put anything in place that will
allow a person to be NOUPDATE on one screen and not another.

But, this has worked for us in the few cases where we wanted users
to access the same screen without being able to alter data, yet
not have to write a clone screen..

rich@thestewart.org

-----Original Message-----
From: John Pearce [SMTP:jpearce@rmi.net]
Sent: Wednesday, March 17, 1999 10:11 PM
To: powerh-l@lists.swau.edu
Subject: What's the best way...

What's the best way to have a single screen serve two sets of users (based
on user class) where one user class can do everything (enter, update,
delete) and the other user class can only inquire on existing records?

                                            
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.