Question:
I have a question about allowing a user to make changes to some fields and having other fields dimmed or hidden.
I was able to do this using IMG for an FI application, by assigning fields to a group and then contolling the access through the object F_LFA1_AEN and assigning VGRUP certain groups.
I would like to do something like this for the MRP area under MM02
If a user has MM02 and they pull up a material number and then MRP1 for a particular Plant and Storage Location, I want them to be able to change MRP type field but not another field in the same block of data such as the MRP area,
I am understanding that this is not possible with Authorization Objects and values in a role alone.
The method in the IMG for configuring the Material Master, seems like it might be the correct solution. But....Why wouldn't the creation of a Transaction_Variant work like (MM02_Whatever) using SHD0. Is it not possible to do this with this particular situation because you are not able to configure all of the screens?
SHD0 allows you to create a transaction that will allow you to "record" setting on each screen so that you could hide some fileds or make them display only, and then when you are finished with all the fields and screen settings you save it and transport it. The result might be MM02_NOTSODANGEROUS transaction that the user can execute. Technically they may still have the authorizations in their job role to change the fields but the fields you selected are dimmed or hidden so they don't know how to get around that, and they are in practice, blocked.
I played with it up to the point of creating a transport, then backed out. It seems like it would work. Does anyone have any experience with securing some applications in this manner?
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Seems like a lot of work for a training issue... What is the Risk (loss to the company)? what is the potential and probability of occurrance?
Low, Low and Low. What is the cost to control? more thatn it is worth.
Yes you can do it the way you want but it may ONLY work if the user follows the steps in the sequence you recoreded, in some cases a "go back one step" may make your fields Re-open.
Answer:
Thanks John,
Since I am not a business analyst I really do not know why the business teams want this. It is something that I have been asked before and I have read about it from others, so it must be a pretty popular need.
When I was playing with the Transaction_Variant, I did see I could disable "Back" and disable "menu options" in different screens. It seems like a great option to add to your solutions list. But I agree I saw right away that we would not be "securing" the access, but rather "hiding" it. But I think that in this case and similar cases that have been brought up before, hiding or dimming fields for some users, and enabling them for others without having to create custom programs was all they wanted.
I am not sure about "a lot of work" What am I missing? The effort to create the transaction variant was just selecting a few screen options, clicking check boxes for what I wanted. As a matter of fact, It was so easy, that I began to doubt it was a good solution, thinking "this probably has bugs or something or everyone would already be using it" for these kind of situations instead of the solutions they implement that take so much more work, like user exits, or programming, or IMG configuration etc.
I am not trying to argue with you, I am trying to learn. I have not even used this method yet, so I certainly do not know anything about it.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
It is very workable but it is a training issue and you are trying to cure the symptom. Further it is opening the flood gates and you will be having to create and support a transaction for every possible scenario that can be brought up and proliferationg roles to allow screen-two-field-one, screen-two-but-not-one-and-field-four, etc.
NOT a good precedent to set. THere are good reasons SAP does not allow what you are proposing.
Answer:
Thanks John,
Would you say the best solution is to use the IMG under
Logistics > General > Material Master > Configuring the Material Master?
I have posted the Quick Guide below. If a business decision has been made to control access to the screens on field level, and telling them (them being people that can fire me) that they should just do a better job training the users, is not a wise choice of action, would you then suggest that the IMG method is the best solution, or something else?
Here's How (Quick Guide Using an Example)
Scenario
For your purchasing agents Kirk, Scott, and McKoy, you want to create a screen sequence containing the following screens:
• Basic Data
You want this data screen to include the following unchanged subscreens from the Basic Data 1 view in the standard material master:
o Material description
o General data
o Dimensions/EANs
• Purchasing/Storage
You want this data screen to include the following subscreens:
o General data (from the Plant Data/Storage 1 view in the standard material master)
o Purchasing values (from the Purchasing view in the standard material master)
You also want this data screen to include an additional subscreen containing the following fields from the Purchasing view in the standard material master:
o Purchasing group
o Material group
o Order unit
Procedure
1. Carry out the IMG activity Create Program for Customized Subscreens . This requires you to do the following:
a) Create a function group of your own, for example, with the name YENTERPRISE (steps 1 and 2 in the documentation for the IMG activity above).
b) Copy subscreen SAPLMGD1 2301 (Purchasing Data: General Data) to SAPLYENTERPRISE 2301 , and subscreen SAPLMGD1 2701 (Storage Data: General Data) to SAPLYENTERPRISE 2701 (steps 3 to 7).
c) Remove all fields from subscreen SAPLYENTERPRISE 2301 with the exception of the Purchasing group, Material group, and Order unit using the Screen Painter (transaction SE51) (step .
Make sure that the fields you have removed are no longer included in checks. You do this by searching for the fields in the source code and making the lines in which they appear comment lines.
Using the Screen Painter, rename the frame text of both subscreens as follows:
General data -> Purchasing data: General data
General data -> Storage data: General data
2. Access the activity Define Structure of Data Screens for Each Screen Sequence, and do the following:
a) Create a new screen sequence, for example, with the ID ZY, by copying screen sequence 21.
b) Select screen sequence ZY and double-click Data screens.
c) With the exception of the data screens Basic Data 1 and Purchasing , delete all other data screens from screen sequence ZY
d) Rename the data screens as follows:
Basic Data 1 -> Basic Data
Purchasing -> Purchasing/Storage
e) Assign the maintenance status L (storage) to the data screen Purchasing/Storage in addition to the screen's present maintenance status E (purchasing) since the screen now contains purchasing fields and storage fields.
f) Select the data screen Basic Data and double-click Subscreens . View the data screen and identify the subscreen assignments you want to delete by counting from top to bottom. In this case, seven subscreens appear on the screen. Delete the third, fifth, sixth, and seventh.
g) Select the data screen Purchasing/Storage and double-click Subscreens . Configure the data screen so that it contains the following subscreen assignments. (Subscreen SAPLMGD1 1005 is required because it contains the organizational level Storage location in addition to Plant.
Program Screen
SAPLMGD1 1005 (material description)
SAPLYENTERPRISE 2301 (purchasing data: general data)
SAPLYENTERPRISE 2701 (storage data: general data)
SAPLMGD1 2302 (purchasing values)
SAPLMGD1 0001 (blank subscreen)
SAPLMGD1 0001 (blank subscreen)
3. Check the order of the two main screens in the activity Maintain Order of Main and Additional Screens.
4. Assign the screen sequence ZY to the purchasing agents Kirk, Scott, and McKoy in the activity Assign Screen Sequences to User/Material Type/Transaction/Industry Sector (where this example is briefly continued in the documentation).
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
I would tell them it is a training issue, it is YOUR mone as well....
Answer:
It is security's responsibility to provide cost effective control comminseurate with the postenital risk. I ALWAYS tell the requester "You can do whatever you like in SAP, it all depennds on how much you want to spend in the short run and in long-term maintenance". I also ALWAYS tell them when it is a training issue not a security issue. You do your company no servide by ablidging. If they intend on firing you that would have occured long ago, do not be baligerant, just frank and honest. and ALWAYS DOCUMENT the decision so when they come back and ask why security is so expensive....
It never hurts to present the requester with an alternative, i.e. configuration ( usually this is the root of the problem , they do not know it is configurable). SAP security is what it is, Industry standard controls. So why did they by an industry standard compliant system if they are not going to use it.
Let them decide
Answer:
Thanks John,
I was just kidding about the firing comment I am not concerned about that, I was just trying to find the best solution. I agree it would not be a good option to suggest a fix that costs more to implement and maintain than the problem warrants.
I guess field level authorization groups defined by the Security Administrator, and tied to a Table Authorization Group, is too much to ask?
Then I could use auth group S_TABU_DIS with auth group I assign to MARC table, and S_TABU_LIN and field auth group and control field level access.
Probably scheduled to come out with SAP Federation Release 9.0
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net