On Sep 6, 2:44 am, Elliot wrote:
> Hi everyone,
>
> We're having problems getting newly created objects to have the
> correct permissions. The approach we use has been in use for over 10
> years and is supposed to handle newly created objects. However when we
> really looked at it recently it just did not seem to be working.
>
> Here's what we've been doing. We use group profiles and referenced
> objects to give *ALL authority to members of the group that needs to
> use our software. Existing objects are getting the correct authorities
> with:


I suspect if you look at the joblog for the change, you'll see a "not
authorised to object" error. In order to grant authority to an
object, you need to either be the owner of the object or have OBJMGT
authority to it. As FAC01 is not the owner of the object, nor does it
have specific authority to it, it will be getting its authority via
*PUBLIC. As this is only *CHANGE, it does not have OBJMGT authority.
You may have to create a program that adopts authority to perform
these changes.

It seems that although the user MAGNAL may be a member of group FAC01
as alluded, that profile presumably does not have one of either the
OWNER(*GRPPRF) or GRPAUT(*ALL) set; see ?CHGUSRPRF USRPRF(MAGNAL).
As far as the authority given to the user creating the object, that
is consistent with the above inference, in that for user MAGNAL having
*ALL authority, the creator is probably the owner.
[If offered,] the AUT() parameter establishes the public authority;
user [special value] name *PUBLIC. The default public authority is
AUT(*LIBCRTAUT) in most cases, so the authority value specified in
CRTAUT() parameter of the request to CHGLIB LibName CRTAUT(Aut_Value)
would determine authority granted to *PUBLIC. That value could be an
authorization list [type *AUTL] object for which a pre-established list
of authorized users and public authority could be set. Having an
authorization list could replace reference object processing.
Note: Authority setting is additive, so if a user already has
*CHANGE, granting by reference does not drop authorities. Note also
that *EXCLUDE is tracked as an additive value, so that specific special
value might appear to conflict with the former comment -- if one were to
infer *EXCLUDE meant /less than/ *CHANGE.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

Elliot wrote:
> We're having problems getting newly created objects to have the
> correct permissions. The approach we use has been in use for over 10
> years and is supposed to handle newly created objects. However when we
> really looked at it recently it just did not seem to be working.
>
> Here's what we've been doing. We use group profiles and referenced
> objects to give *ALL authority to members of the group that needs to
> use our software. Existing objects < > desired authority of *ALL; and something about grant by reference>>
>
> On the other hand authorities for a newly created file by user in
> FAC01 group DO NOT refer to the group and *PUBLIC has been changed
> from *USE to *CHANGE
>
> Object
> User Group Authority
> MAGNAL *ALL
> *PUBLIC *CHANGE
>
> What do we need to do to get newly created objects to use the
> reference object for its authorities?

Chuck

It seems that we can either set OWNER(*GRPPRF) or GRPAUT(*ALL). What
are the differences and advantages of each approach?

As stated above, the goal is to allow all members of the group *ALL
authority for any objects created by group members and I would like to
find the simplest way of achieving this.

Thanks, Elliot

On Sep 7, 7:57 am, Elliot wrote:
> Chuck
>
> It seems that we can either set OWNER(*GRPPRF) or GRPAUT(*ALL). What
> are the differences and advantages of each approach?
>
> As stated above, the goal is to allow all members of the group *ALL
> authority for any objects created by group members and I would like to
> find the simplest way of achieving this.
>
> Thanks, Elliot

Methods to use will vary depending on the process used to create these
files and the best way to suit your environment. If the program
creating the file is also changing the object authorities, it could
adopt authority to allow it. If that's not possible or not ideal,
then Chucks suggestion is another alternative. The differences
between the options are...

If you change the profile to OWNER(*GRPPRF), then when an object is
created by such a user, the object will be owned by the users group
profile. e.g.
User profile ProfileA has group profile GroupA and OWNER(*GRPPRF)
If ObjectA is created, it will be owned by GroupA with *ALL authority.

If you change the profile to GRPAUT(*ALL), the object will be owned by
the individual, but the group profile will have *ALL authority granted
to it. The GRPAUTTYP parameter will determine if this is granted as
the primary group of the object or as a private authority. e.g.
User profile ProfileA has group profile GroupA and GRPAUT(*ALL)
If ObjectA is created, it will be owned by ProfileA and GroupA will be
granted *ALL authority.
If GRPAUTTYP is set to *PGP, then the group profile will be the
primary group, otherwise it will be a private authority.

I personally prefer to use OWNER(*GRPPRF) so deleting profile is
easier. If owner is *USRPRF, when the person leaves the company you
will need to either delete any owned objects or change the ownership
so you can remove the profile. If your situation means changing the
ownership of the objects, then it is likely you will change it to the
group profile, so it makes sense to do it that way at the start.

Thanks for the clarification.
Sounds like OWNER(*GRPPRF) will work fine for us.

Elliot