Authorization Issue in Project Management

[ladinca]

Hi experts,

We are in PPM 5.0

We have 2 users, USER1 and USER2

USER1 : log on to PPM --> Project Management Screen --> Create New Project PRJ1

USER1 is defined as Administrator for that project --> USER1 can view and change anything on that project

USER2: Log on to PPM --> Project Management --> Search function --> search for project PRJ1

He finds it, can also edit everything on it.

Why?

We expect that who is not authorized cannot change anything.

Regards.

Laura

[hanspeterbaier · Accepted solution]

Hi Laura,

There is an authorization object called ACO_SUPER that overrides the given ACL authorities from the project. Can you check the (backend) roles of USER2, if he has ACO_SUPER?

For the search help there is a special circumstance: When calling search helps the ACL authorities of the projects are not processed. Therefore you can find all projects accross the organization but if you try to open a project the authority check (of ACLs or back-end roles with auth.objects like ACO_SUPER) is done. This is SAP-standard behaviour for search help and at the moment this can only be "fixed" with customer enhancements or SAP consulting solutions ("security package").

regards,

Peter

[ladinca · Accepted solution]

Thank you, I can mark your answer as the correct one

Is there a possibility to allow the display of projects to a user in Read Only using authorization objects?

Kind Regards.

Laura

[hanspeterbaier · Accepted solution]

Hi Laura,

unfortunately it is somewhat complicated. The "super" authorization object ACO_SUPER can be maintained with "read" activity, so that the user can access all projects in read-only mode. Unfortunately you can't get more specific authorizations to projects via this authorization object.

There might be another variant via BAdI implementation and the authorization tab "roles". Perhaps this solution will fit to your request.

1) On tab "roles" you can insert back-end roles. This roles don't need to have any authorization objects, they can exist as empty shells

.

2) Implement the BAdI DPR_ATTRIBUTES with methods SET_DEFAULTS_UPON_COPYING and SET_DEFAULTS_UPON_CREATION

3) With these two methods you can set the back-end roles depending on attribute that fit your use-cases, e.g:

• all projects with a specific project-type gets a specific role with ACL activity  "read"
• in case of a specific org.unit a special back-end role is set with "read".
• and so on, you can imagine of other attributes like priority, custom-fields... to use with this BAdI-implementation.

The great advantage of using the "roles" tab is, that you can change the authorization in back-end with mass-editing and very easy and fast (of course for the defined use-cases only). Unfortunately there is no mass-editing of authorizations in PPM yet.

regards,

Peter