Conference iosg::all-in-1_v30

1119.0. "restricted access to part of an application" by FAILTE::TODD (ET phone home) Fri Jul 24 1992 16:19

Hi,

We have here an application for our admin group, it is to record when 
customers orders are received.  It comprises of 5 menus. The people who 
currently access it have in their form library OA$site_lib:TRACK.FLB.


The problem;

How can I give others read only access to a part of this. 
This is how it runs

(ADMIN$MENU)
                       ADMIN TRACKING ORDER - MAIN MENU


         SEL  Select        CUSTOMER NAME:   BP EXPLORATION
                            P.O.NUMBER    :  BRUP87301
         C    Create        ADMINISTRATOR :  KABE
         E    Edit
         D    Delete
         R    Read
         CPO  Change Purchase Order Number


         Rep  Report

         RI   Recall Index

If I type REP it takes me to ADMIN$INDEX

                             REPORT GENERATION FORM
                                                                        
       CUSTOMER NAME :                                                  
                                                                        
       PURCHASE ORDER NUMBER :                                          
                                                                        
       ADMINISTRATOR :               ASSET :                            
                                                                        
       DATE RECEIVED :                   TO :                           
                                                                        
       PURCHASE VALUE :             .00  TO             .00             
                                                                        
        Please enter as many details as you can and then press RETURN

If I type BP in Customer Name and hit return it brings me up ADMIN$SELECT

                          Index of appropriate orders

   CUSTOMER NAME                 DATE           VALUE         ORDER NUMBER

1  BP EXPLORATION            23-Jul-1992         5000.00 BRUP87301
2  BP EXPLORATION OPERATING  03-Jul-1992         6400.00 COXIT10281004
3  BP EXPLORATION            23-Jul-1992         2500.00 COXIT10281005
4  BP CHEMICALS              20-Jul-1992         1200.00 DM25201EW
5  BP CHEMICALS LTD          09-Jul-1992        63704.00 DM25202

If I select 1 it takes me back to ADMIN$MENU where I sel R and can read it

Brings up ADMIN$ENTRY
                         ORDERS ENTRY 
                           
        PURCHASE ORDER NUMBER: BRUP87301                                     
                                                                             
        CUSTOMER NAME : BP EXPLORATION                                       
                                                                             
        DATE RECEIVED :  23-Jul-1992         PURCHASE VALUE:  5000.00 
                                                                             
        ADMINISTRATOR : KABE                 ASSET : N                       
                                                                             
        ENTERED BY : KABE                                                    
                                                                             
        SENT TO : ?                                                          
                                                                             
        COMMENTS : MAIL TO TONY DEANS - QUERY WITH P/O                       
  
Press RETURN to finish reading

What I want is for other users only to be be able to go through the loop 
and select a record but only have access to the R option.  Is this possible 
and if so how?

Thanks in anticipation.

Liz




Presently admin$index displays the records but allows the users to Edit 
Delete etc

    
    Liz,
    
    How about separating the forms in two forms libraries.  TRACK.FLB and
    TRACKREAD.FLB.  All users would open TRACKREAD.FLB but only those 
    users that could write records would open TRACK.FLB. (They would open
    TRACK.FLB _before_ they opened TRACKREAD.FLB.)
    
    Both forms libraries would have copies of ADMIN$MENU, but the one in
    TRACKREAD.FLB would now allow edits.
    
    HTH,
    
    Jack

    
> Both forms libraries would have copies of ADMIN$MENU, but the one in
> TRACKREAD.FLB would now allow edits.
    
    That _should_ be:
    	...would NOT allow edits.
    
    Jack
    
    

	In addition to Jack's suggestion, you could also take several other
approaches.  One would still present all users with all options, but when any
option was selected by a user who couldn't perform that option, a simple message
would be displayed.

	Another approach is the "context-sensitive menu" approach used by V3.0
Customization Managements, where the options presented vary from situation to
situation.  This comes closer to Jack's approach, but is more dynamic.  (It's
also much more of a headache to program!)

	F

    Hi,
    
� situation.  This comes closer to Jack's approach, but is more dynamic.  (It's
� also much more of a headache to program!)

    I know of an application were the BA menu is totally dynamical, and can
    be maintained by a specific authorization manager, using a standard
    ALL-IN-1 interface. Using startup-scripts in which FLB's can be opened
    (and closed) you'll never have the FRMLIB length problem. An additional
    feature is that you can create dynamic sub-menu's as well (without
    having ALL-IN-1 programming knowledge!), to maintain sub-application
    authorization, which will easily solve .0's problem.
    
    Sorry, it's not Digital's (yet).
    
    Regards,
    Sjaak.