Conference iosg::all-in-1_v30

    Martin,
    
    what is not correct? does the user have PRVXOWN - see note 34.
    
    Regards,
    
    Andrew.D.Wicks

Hello Andrew,

>    what is not correct? does the user have PRVXOWN - see note 34.
    
As specified in .0 user doesn't have any privileges, so also no XOWN privilege

The problem is that a "normal" user without any ALL-IN-1 privileges is not able
to create documents using template documents a standard ALL-IN-1 functionality.

1. Create a document by specifying drawer, folder and name and press NextScreen
2. Specify the template (drawer, folder, title).

I don't understand why a user should have this privilege, merging is done in a
lot of places within ALL-IN-1 without complaining about this privilege.

Regards,

Martin

Hello,

This morning I showed the behaviour to my collegue Jan Schollaert and he also 
said this is a bug.

Is it SPR time ?

An official commitment would be appriciated !

Regards,

Martin

    Well, this is still true in v3.1.
    
    It is documented, but perhpas not forcefully enough. Section 4.3.7 in
    the ALL-IN-1 Management Guide, under XOWN privilege, says:
    
    "Y in this field allows the user to execute scripts and document
    templates in the user area ..."
    
    (It doesn't say, but does imply, that N in this field will take these
    facilities away).
    
    We had a lot of trouble defining the way these new (in v3.0) privs
    worked, because a number of the things ALL-IN-1 does for users from the
    standard user interface can be "abused". Up to v3.0, we always claimed
    that this "abuse" didn't matter, as normal VMS file protections would,
    on a properly run system, prevent the user doing anything seriously
    wrong. 
    
    However, we were eventually persuaded to add these new privs to
    restrict what the user could do, in areas where some customers felt that
    some kind of abuse was nevertheless possible. We tried to do this to
    allow as much as possible of the normal user facilities still to work,
    but this is one area where that just wasn't possible.
    
    You might well feel that an SPR is justified - it might get answered by
    making the documentation more forceful rather than changing the code
    though.
    
    Dave (please note that this isn't an official view, much less any kind
    of commitment. If you want those, you need to talk to the product
    manager.)

Hello Dave,

Thanks for your opinion.

Maybe the documentation could be enhanced as follows:

XOWN
    "Y in this field allows the user to execute scripts and document
    templates in the user area ..."
    Futhermore allows users to execute UDPs and merging WPS-PLUS Document
    templates.    

>    You might well feel that an SPR is justified - it might get answered by
>    making the documentation more forceful rather than changing the code
>    though.

Changing the code seems to me a tough job, I would prefer a document change.
I'll ask the customer how he feels about this..

Thanks,

Martin

Hello,

I talk to the customer. He doesn't accept the explanation. He also states "I
don't need the XOWN privilege when I execute UDP's, why should I need this
privilege when I do something which is (was) a standard ALL-IN-1 functionality"
I create a document using a template document and as user I'm not interessed in
merge functions and XOWN privileges. If ALL-IN-1 needs a merge operation to
do its job, ok, but it should complain not having a privilege !

So he'll sumbit an SPR (IPMT)

Martin

The Template Document selected from the Creating New Document form has 
always been MERGED, and not just copied.  This means that it can contain 
MERGE directives, including <&OA function\...> which therefore provides a 
mechanism to do application programming.  It is for this reason that this 
operation is controlled by the ALL-IN-1 XOWN privilege.  MERGE operations 
from compiled files are allowed but MERGE operations from non-compiled 
files are not, and the source template document is an example of a 
non-compiled file.

UDPs are sets of keystrokes entered at the normal user interface, and
therefore are not controlled by the XOWN privilege.  For security reasons
the ability to execute application programming functions is controlled by
ALL-IN-1 privileges.  Executing keystrokes from a UDP is not equivalent to
executing application programming functions. 

ALL-IN-1 V2.4, and earlier versions, did not have XOWN privilege but all
users could perform the operations which are now controlled by this
privilege.  By not granting users the XOWN privilege the customers has
decided to further restrict what users can do.

Another method of creating a document from the contents of another
document, without performing a MERGE, is to use MCD (Make copy of document)
to make a copy of the 'template document' and then edit the new document.


Richard 

Hello Richard,

Thanks for your (engineerings) point of view.

> The Template Document selected from the Creating New Document form has 
> always been MERGED, and not just copied.  This means that it can contain 
> MERGE directives, including <&OA function\...> which therefore provides a 
> mechanism to do application programming.  It is for this reason that this 
> operation is controlled by the ALL-IN-1 XOWN privilege. 

Mr. Customers answer:

My template documents are plain text documents without any merge directives, so
I don't use and need the API's. So for merging plain text template documents the
XOWN privilege isn't needed, however if one decides to use merge directives in
his template document than the XOWN privilege is needed.

end of Customer's answer.


As the customer already has submitted an SPR, I think it is better to close this
topic. There always will be customers which are never 100% satiesfied.

Martin

p.s. My own opinion is "Granting XOWN privilege isn't a big deal." I know a lot
     of sites which grant this privilege by default to ALL users.

    If the customer is sure that his "template" is really going to only be
    text for ever, then you could customise it to do 'MCD' rather than a
    merge. You could even be clever and conditionalise that based on
    whether the caller had XOWN.
    
    Graham
    
    PS I suppose we should do that in the base....