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: 

Prevent users from changing material master description for ROH

Former Member
0 Kudos

Hello, Experts! We have a situation here where we need to prevent certain users from making changes to the Material Master description, but only for ROH Material Type. Can this be done in any way without impacting those users' ability to change description for other material types?

Your input is greatly appreciated.

Thank you!

15 REPLIES 15

arpan_paik
Active Contributor
0 Kudos

Can you please give us some more info? Like which txn? which are the associated object/traced object?

Regards,

Arpan Paik

0 Kudos

Can you please give us some more info? Like which txn? which are the associated object/traced object?

>

> Regards,

> Arpan Paik

Hi Arpan,

Sorry for the question but, how many transactions do you think we have for Material Master changes?

0 Kudos

Hi Shekar,

I do not have any idea on txn for this one (some MM* ?). But for material type is there any auth field? Seems like I have seen one (M_MATE_??) but can not confirm until look into a system which I do not have right now

Edited : A google search for this topic through object name M_MATE_MAR.

Regards,

Arpan Paik

Edited by: P Arpan on Aug 17, 2011 3:01 PM

0 Kudos

Hi Shekar,

>

> I do not have any idea on txn for this one (some MM* ?).

that's a surprise

But for material type is there any auth field? Seems like I have seen one (M_MATE_??) but can not confirm until look into a system which I do not have right now

>

> Edited : A google search for this topic through object name M_MATE_MAR.

Google didnt lie , the object indeed is M_MATE_MAR

But the problem here is not in restricting on the material type, which i presume the OP understands. The problem is the Material text (MAKT-MAKTX) which can be maintained from the additionla data tab in the material master(ctrl+F6), there is no authorization object that controls this field. unless there is a modification made to the user exit you cannot achieve the objective and take my word if you wish - it is a complex and tricky job that will eventually come back to 'haunt & hunt' for good

0 Kudos

that's a surprise

To solve a typical Security problem do I need to be business process expert? By the way knowledge is good and may be some other time it will be with me

The problem is the Material text (MAKT-MAKTX) which can be maintained from the additionla data tab in the material master(ctrl+F6)

If a user has a display access to M_MATE_MAR still it cannot be controlled?

Regards,

Arpan Paik

0 Kudos

If a user has a display access to M_MATE_MAR still it cannot be controlled?

> Regards,

> Arpan Paik

I give it to you. You do have a good sense of humour

The discussion i thought was about change access and not display - isnt it?

0 Kudos

Let's go back to original question...

We have a situation here where we need to prevent certain users from making changes to the Material Master description, but only for ROH Material Type

So if we go ahead with not to provide change access to those certain user for ROH material type in M_MATE_MAR, still those certain users will be able to change description for material type ROH? It's a question from my end. It's too bad as I do not have a system so I cannot simulate this. I am talking on logical ground not on actual fact.

Regards,

Arpan Paik

0 Kudos

Let's go back to original question...

>

We have a situation here where we need to prevent certain users from making changes to the Material Master description, but only for ROH Material Type

> So if we go ahead with not to provide change access to those certain user for ROH material type in M_MATE_MAR, still those certain users will be able to change description for material type ROH? It's a question from my end. >

> Regards,

> Arpan Paik

Arpan,

If we restrict access for Material type ABCD, then we can change the text for ABCD. If we do not give access to ABCD in M_MATE_MAR then the question of changing the material text of ABCD does not arise.

If i understood the OP's problem right, i presume that the OP would like to restrict few users from chainging texts for ROH material type only. I infer that the set of users have access for ROH maintenance but the OP wants these set of users not to change the texts - as i said, this cannot be achieved with authorization objects

0 Kudos

I infer that the set of users have access for ROH maintenance but the OP wants these set of users not to change the texts - as i said, this cannot be achieved with authorization objects

That sounds additional level of segregation. Anyway let them come back after changing lot of role.

Regards,

Arpan Paik

0 Kudos

But the problem here is not in restricting on the material type, which i presume the OP understands. The problem is the Material text (MAKT-MAKTX) which can be maintained from the additionla data tab in the material master(ctrl+F6), there is no authorization object that controls this field. unless there is a modification made to the user exit you cannot achieve the objective and take my word if you wish - it is a complex and tricky job that will eventually come back to 'haunt & hunt' for good

For this, I've got a question: to allow users only to change the material descriptions texts through additional data there is a user exit? Where can I find more info about this mentioned user exit?

In a system users should be allowed to change only material descriptions in a certain language, for example EN. So I tested that for changing minimum following authorization objects are necessary:

M_MATE_STA with ACTVT 02 and STATM with K

M_MATE_MAN with ACTVT 02

With these authorizations all texts could be changed.

Regards,

Julia

0 Kudos

Hi,

I've just had to do the same and as the details of a solution haven't yet been posted I thought I'd add how I achieved it. You a developer to do this.

Create new authorisation object and assign to the profiles of the users who should still be able to make the changes.

Activate user exit EXIT_SAPLMGMU_001

Edit include zxmg0u02

Table STEXT contains the description as entered in the transaction.

Read the old description from table MAKT

Compare the old description with the new description

If they are the same then no need to check further

If different, check the material type and any other important information

Do authorisation check for newly created authorisation

If permitted no further action required

If not authorised, I return an error message stating that the user is not authorised. This returns the GUI back to the transaction at the point at which they tried to save the changes without saving the changes

Hopefully this will help others out there.

John

Former Member
0 Kudos

Hi Nancy,

controlling the material text via authorization objects is not possible. you would have to indulge in some code changes in the user exit

Former Member
0 Kudos

Thank you both for all of your assistance with this! I have been sharing your responses with our security person here, and she has been doing some testing, which seems to be going quite well (we have a number of Roles to modify and test, so it may take a while longer). I am MM/PP Functional Support, so don't know all the ins and outs of what she's doing in security. After our testing is complete, I will have her provide detailed info as to what she did and post the info in this thread.

Thank you again!

0 Kudos

we have a number of Roles to modify

This is often the case for single roles when you use composite roles for user assignment (at first...).

Hold your braces, chin up and good luck when changing the single roles...!

Cheers,

Julius

0 Kudos

This message was moderated.