[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

1149.0. "moving form to base area resets protection." by AIMTEC::SIMPSON_L () Thu Jul 30 1992 16:33

Hello,
    
    We have a customer who is using ALL-IN-1 V3.0.  He has run across an
    interesting situation and wrote to ask us about it.  The problem is
    described below.  We suggested to him that he set the protection as
    desired on the directory which contains the form library.  Does anyone
    have
    any other ideas after reading the rest of the note?
    
    Any comments would be greatly appreciated.
    
    Thanks very much.
    
    Laurie
    Hi,

I have created an application called NB and and area called LLV.  Frequently
when I move a form the the "base area", the form library NB$LIB_NB_LLV:LLV.FLB
ends up with the protection (S:RWED,O:RWED,G:RE,W:) despite the fact that I'd
previously set the file to have W:RE access.  I think the problem lies
"primarily" in CM_SM_MOVE_BASE_FRM in the line that starts

.IF #CM_SET_PROT NES "" THEN GET OA$FUNCTION - ...

(it's about 10 lines after the label REPLACE_FRM).

The crux of the problem is that by the time this gets called, FMS has already
created a new version of the form library.  The way the call is contructed,
(P4=P6 and P5=Y), no change in protection can occur.  I think that P5 should
really be "N".

Whhat do you think?


Thanks,
Bruce Bowler



Yes, it happens sometimes and not others.  From experimentation, it seems to
happen once per ALL-IN-1 session.  In 1 session, if I move one form, then
manually reset the protection to include W:RE, subsequent moves of forms won't
reset the protection (because FMS didn't create a new version of the FLB)


The protection on the directory is (S:RWE,O:RWE,G:RE,W:E) with an ACL granting
holders of OA$PRVAPP READ access.  I'm *very* relucatant to open up the
protection to W:RE as this will permit "snooping" by the users.


The problem here is a *very* subtle one.  When CM_SET_PROT is called, if
P4=P6 and P5=Y, then the call is useless and should be omitted since what it
does is to set the protection on P4 to be like the protection on P6.  If P4 and
P6 are the same, then it sets the protection on P4 to be the same as the
protection on P4.


Thanks,
Bruce Bowler

T.RTitleUserPersonal
Name
DateLines
1149.1Yes, 5th parameter should be 'N'47215::EIJSAll in 1 PieceFri Jul 31 1992 09:2024
    
    Hi Laurie,
    
    Your customer is right. The CM_SM_MOVE_BASE_*.SCP should call
    CM_SET_PROT.COM (or better CM$AUTH$LOCATIONS.PROTECTION[#CM_LOC_KEY])
    in such a way that it uses 'element.type;-1' (either procedure or
    library) as the base. The CM_SET_PROT.COM is basically written for
    elements moved to the Live area, which then uses the Base element (if
    one available) or the Live one as a template. However, it can also be
    used for elements moving to the base area by using it in a different
    way.
    
    The fifth parameter indicates if the file being moved is a Standard
    file (meaning it has a record in CM$SDC). If so, it uses the base file
    as the template, else it uses the 'Live file;-1' as one. In case the
    element is moved to the base area, you need the 'Base file;-1' as the
    template. The way to use CM_SET_PROT.COM for this is defining the fifth
    parameter as 'N'.
    
    I've reported this.
    
    Thanks,
    
    	Simon