[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

1543.0. "Restrict ALL-IN-1 functions" by CHEFS::LEEB () Thu Oct 01 1992 15:57

    
    Can anyone help with this request frem a user.
    
    A number of accounts have been set up to allow temporary staff to use
    an ALL-IN-1 application. They are all captive accounts which take the
    user directly to the first form in the application. None of these
    accounts should need to access the 'normal' ALL-IN-1 functions (mail,
    WP, etc.).
    
    Is there any way of preventing users in these accounts from having
    access to these functions. I have tried setting up a USER.FLB with
    dummy menus etc. but the default menu always appears.
    
    thanks
    
     Barrie

T.R	Title	User	Personal Name	Date	Lines
1543.1	You pay your money, you take your choice	A1VAX::BARTH	Shun the frumious Bandersnatch	`Thu Oct 01 1992 16:07`	23
	There are lots of ways to implement this sort of restriction. One way is to close the form libraries with all of the "normal" forms. Another way is to make the initial form in the application define EXIT, GOLD K, GOLD Q so that they can't "back up" to the main menu. Combine this with /CAPTIVE on the application menu so they can't pick options that aren't defined on the app menu. Another way is to flip a USERnn switch in their profiles and modify the DEFAULT menu (and/or other forms) to check the switch before moving the user off of the application menu. Another way is create a new DEFAULT menu (called, say, XYZ) which doesn't recognize the global menu options in the normal DEFAULT menu (EM, WP, etc) then SET_MENU XYZ so that key definitions and global options come from XYZ instead of form DEFAULT for the restricted users. I'm sure there are other techniques. You get the idea. ~K.
1543.2	How about /VALID=OA$TABLE="...."	GIDDAY::SETHI	Man from Downunder	`Fri Oct 02 1992 01:50`	23
	G'day Barrie, >Is there any way of preventing users in these accounts from having >access to these functions. I have tried setting up a USER.FLB with >dummy menus etc. but the default menu always appears. I have done this in the past when I wrote an application and I needed to bar user from accessing "normal" ALL-IN-1 sub-systems. The way I got around the problem was to use the /VALID qualifier on the choice field. For example /valid=oa$table:"A,B,C", if the user entered anything else other than A,B,C ALL-IN-1 displayed Invalid choice. This I found was the easiest way to get around the problem. Play around with this as I have said I remember doing this many years ago now. Good luck Sunil
1543.3	Protect other menus in forbidden subsystems...	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Fri Oct 02 1992 12:43`	12
	If you don't use Sunil's good suggestion in .2, remember that yoiu can get to a menu directly by typing its name. So even if you take the WP option off the DEFAULT form, you can still get to the WP form (which is called WP!) by typing WP.... So you may need some checks in the /PRE of the forms you want to protect, or some dummy definitions in DEFAULT for all the forms you want to prevent access to. If you look in the shipped DEFAULT, you'll see similar code for SA$SHUTDOWN, SA$CHECK$CREATE etc. Graham