STRUCTURAL AUTHORIZATION (Training & Events Management)

[gangadharrao_tenneti]

Dear Friends,

Through STRUCTURAL AUTHORIZATION we maintained following:

DISPLAY access to object type O (Org Unit) and

MAINTAIN access to object type D (BE Type).

Issue is when we are creating relationship A 036 (Is organized by) between D and O.

System throws an error message saying that INST authorization is missing for Object type O.

But actually we should not / don't need, Maintain authorization for Object O.

How can we achieve this issue, with-out giving maintain access to Object type O.

Note: We are using L-D-E-E Evaluation path for object type D.

And Evaluation path L-D-E-E is customize i.e., Updated with object type O and relation A 036 with D, still it doesn't solve the issue.

Regards,

TG

[AFS · Accepted solution]

Hi,

when creating a relationship in HRP1001, always two relationships are created: the one you create (like in this case D A036 O), and the inverse relationship (O B036 D). So you need to have authorization to maintain both objects.

Regards,

Ana

[gangadharrao_tenneti · Accepted solution]

Many thanks and Fully agreed with you.

But still we don't want user to maintain object type O, If I give maintain access to O then users can create / change object O, which is not accepted at all.

You know we just stuck here, how can we give only A 036 relationship access to Object O with D.

Even if I maintained this relation in evaluation path it doesn't work.

How to achieve this issue... PLEASE need some solution.

[gangadharrao_tenneti · Accepted solution]

Any more suggestions..?

Still waiting

Edited by: TG on May 14, 2011 9:42 PM

[Former Member · Accepted solution]

You give maintain access only to infotype 1001. Then they cannot maintain object O. They need maintain access to infotype 1000 to be able to update the object itself. So it is quite safe to give access to 1001 and the needed relations.

Kirsten

[gangadharrao_tenneti · Accepted solution]

Dear Kirsten,

In such case no need of structural authorizations.... right? and one more thing is it possible to create two different roles one is for change and another is for display.

will it do, as required??

Regards,

TG

[Former Member · Accepted solution]

Hi again,

Whether you use structural authorization depends on your needs. In our implementation we use both structural and regular authorization. Regular authorization determines what the user can do to each object/infotype. Structural authorization determines where (which part of the organization) the user can do these operations.

We normally give write access to all objects in structural authorizations. All users have the same structural authorization. A function module dynamically determines the structure each user can operate on. Users then have different roles to distinguish who can update and who can only read eg. O.

So yes, you can create 2 (or more) roles.

Typically, you would assign one role to your HR people and another role to Training and event people.

The HR role could have full access to object O all infotypes. Maybe just read access to D (depending on how work is split up in your organization).

The T&E role would have read access to all infotypes for O and D, but full access only to infotype 1001, relations A036, B036.

You use several instances of the authorizaton object PLOG in each role to achieve this.

Hope this answers your question.

/Kirsten

[gangadharrao_tenneti · Accepted solution]

This has been achieved using combination of Aspects and Role Authorization.