[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines |
---|
1149.1 | Yes, 5th parameter should be 'N' | 47215::EIJS | All in 1 Piece | Fri Jul 31 1992 09:20 | 24 |
|
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
|