cancel
Showing results for 
Search instead for 
Did you mean: 

Display BP Screen - Hide Address UIBBs if record contains certain BP role

Former Member
0 Kudos

Hi SCN,

I am looking for some help with a requirement and any direction would be much appreciated. I am on MDG7.0 SP03. (apologies for the long post)

Requirement: I would like hide all address related UIBBs when a user views Business Partner records which have a certain BP role IF the current user does not have display access for a specific auth object.

Example Scenario:

BP record #200001 contains the BP role XYZ.

User A has display access for auth object A100.

User B does not have display access for auth object A100.

User A opens the BP record via the MDG BP search screen and is able to see all UIBBs.

User B opens the BP record via the MDG BP search screen and is unable to see the address related UIBBs.

Any ideas how to do this or if it is possible? Is there a class and method that is re-definable which can control the visibility of displayed UIBBs?

I have been able to hide individual fields within UIBBs via redefining the UIBB feeder class method ‘IF_FPM_GUIBB_FORM~GET_DATA’, however was hoping there is a better way.

Initially, I was thinking this could be achieved with a new dimension to the schema BP_ADAPTS in the CBA dimension table FPM_V_ADAPT_DIM.  I added a dimension ‘Role’ with Data Element ‘AGR_NAME’ and set the index to ‘50’ (meaning it should take priority), but the CBA was always triggered – it did not matter if the user had the role or not. Also, this would not take into account if the BP record contains BP role XYZ.

Example of UIBBs I would like to hide.

BS_BP_ADDRESS_STD

BS_BP_ADDRESSES

BS_BP_ADDRESS_USAGES

BS_BP_ADDRESS

I’ve looked at the BADI USMD_UI_EVENT2, however as far as I am aware, this does not work in MDG 7.0.

Any ideas or thoughts would be appreciated.

Thank you,

Peter Melouney

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

You could probably use the FPM application controller. However, I think that is over-engineering the solution. A ready-made simpler solution would be to create different end-user roles. Each role is assigned a different FPM configuration. You can then remove any UIBB permanently from the different FPM configurations. The user who is assigned the proper role will see the appropriate list of UIBB's.

You just need to buy your authorization team a box of donuts and coffee and they will build the roles for you

Former Member
0 Kudos

Hi Abdullah,

Thanks for the quick response.

When you say different FPM configurations, do you mean setting the role as a configuration variant?

Also, the solution of different end-user roles for different FPM configurations would be for all BP roles correct? How would I factor in the concept of only hiding the UIBBs if the BP record being viewed has BP role XYZ?

Regards,

Peter Melouney

Former Member
0 Kudos

When defining user roles, you can build menus with the different FPM applications. In there, you can assign what FPM configurations to be displayed. What this involves is copying the existing standard FPM configurations, modifying the copies and then assigning them to authorization roles.

As for implementing that per different BP roles, you can use the above technique. Then, for each "un-authorized" role, use CBA to hide those fields. However, this will only hide the fields and not the whole UIBB. See this document for how to work with CBA. The BP CBA schema is called BP_ADAPTS.

Personally, I have not been completely happy with CBA implementations. There is something clunky about them and some little thing is always missing. So, you might end up having to do something in the FPM application controller if you get a similar experience. See the FPM developer guide for information on how to use that.

It's been a while since I last did anything with FPM or CBA so things could have improved in 7.4 and my first two suggestions might be easy to do rather than enhance or build a new FPM application controller.

Former Member
0 Kudos

Thanks for the detailed response, Abdullah.

Answers (0)