What's the best way...

[Chris Sharman]

>>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?

It's a very good question. I've never found a very good answer. It seems like
the sort of thing application security ought to do, but I've never seen it
work. Also the 'readonly' users will need write access to the files to run the
common Quick screen: it would be nice if Quick just 'fell back' to a readonly
mode when it couldn't get write access to the data: perhaps a screen
"allowreadonly" clause or something.

>What about having two sets of keys in your program - One for those who can
>do everything
>(The default keys, level 1) and one for those who only can search and watch
>the data (level 2),
>and then check in your INIT and POSTFIND procedures:

Wouldn't work on VMS, unless you disabled all the standard keys. Don't you have
them on other platforms ?

We make sure find-only users start in find mode, and put a catch in the
pre-update to stop them. It's imperfect, but it does the job.
If I wanted perfection, I suppose I'd go for one source, two .qkc's:

@if readonly
screen myread activities find ..
@else
screen myfull ...
@endif
...
You could also put (conditional) "open read" on all the files.

$ qdesign auto=myscreen [cc=readonly]

A similar effect could be achieved with use statements, if you wanted to avoid
cc for the sake of autobuilds: 2 * 2 line files + one main source.

screen myread activities find ...
use therest

screen myfull ...
use therest

<therest>

______________________________________________________________________
Chris Sharman			Chris.Sharman@CCAgroup.co.uk
CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.