Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Restricting SPRO IMG Views using SPRO_ADMIN

Former Member
0 Kudos

Hello

Our goal is to allow business users, to view only a restricted IMG View in Production, when they use Transaction spro.

Our current plan is to do a SPRO_ADMIN project view with IMG view ,and add it as a role to the users.

Does someone have any notes,help to do this?

Or Do you guys suggest any alternate ways to restrict the IMG View in Production?

Thanks

Prakash

5 REPLIES 5

Former Member
0 Kudos

Hi Prakash

This is pretty straightforward.

1. Create your IMG view/s in SPRO_ADMIN

2. Fire up PFCG and create a role

3. In menu tab click on Utilities->Customising Auth

4. Add the IMG proj/view that you created in SPRO_ADMIN

5. Make sure that there are only display activities in the auth tabs.

Hope that is what you are after.

Cheers

Alex

0 Kudos

Alex

Thanks for the answer.

I created the role, but

1. Do I still have to add member to the project each time? If the member, can be added to the project just by role assignment in PFCG , that would be great.

2. How about Authorizations?

Currently we restrict the support personnel in production, to some defined transactions. When we look at the authorizations in the role for spro, it has several transactions.

Can you please suggest me an approach?

Our idea is to assign a restricted spro view, as a transaction based production position.

Thanks

Prakash

0 Kudos

Hi Prakash

1. Add the role to the user to give them the access

2. SPRO contains a very large number of transactions and as you have found out even parts of a node have a good number of tx. This is standard and the users need access to these to be able to see the relevant node items.

Your support people should already have very restricted access in production so additive auths shouldn't be a problem. Ensure that their other roles don't have S_TABU_DIS activity 02 auth group = * typically having the system locked and in production status should prevent changes but you need to control at auth object level too.

0 Kudos

Alex

Thanks for the reply.

The thing scaring us is that currently support hold other transaction based positions (s_tabu_dis 2) now by adding display SPRO, it should not give them table change option from other functional groups, when the production client is unlocked.

How does companies usually handle this?

We have been putting SPRO in firefighter just because of this scare and we have been asked to reduce our firefighter usage.

So in short can spro display, coexist with a transaction based support position in production?

Thanks

Prakash

0 Kudos

Hi Prakash,

First of all general support roles should never have S_TABU_DIS with ACTVT 02 auth gp *. They should be limited to solely the auth groups on the tables that they need to change via the admin transactions. BASIS are a typical exception (but that still doesn't make it right!). They should restricted to only the transactions that they need to execute and there should be no direct table maintenance.

If this is in place, then the risk of giving SPRO display in prod alongside the support roles is reduced and one which is accepted in many organisations.

As the control over table access doesn't appear to be in place then having SPRO Display in firefighter sounds like a reasonable mitigating control. As far as I am aware there is no fee for usage in FF so as long as your process is OK there shouldn't be any problem with continuing to do it that way.