on 07-09-2015 10:00 AM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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.
User | Count |
---|---|
95 | |
11 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.