Planning

Get Involved. Join the Conversation.

Topic

    Krishna Sangli
    EPBCS Dimension Security by module
    Topic posted August 30, 2018 by Krishna SangliGreen Ribbon: 100+ Points, tagged Financial Planning, Planning, Workforce 
    711 Views, 7 Comments
    Title:
    EPBCS Dimension Security by module
    Summary:
    Setup EPBCS dimension security by module
    Content:

    Hi , 
    Please let us know if we can setup dimension security by module. 
    We want to provide access to a user for entities ,Entity1 to Entity10 in Financials module whereas restrict the access of the same user to only Entity1 and Entity2 in workforce module. 
    Please let us know if EPBCS supports setting up security by module .


    Thanks 

     

    Comment

     

    • Mark Rinaldi

      Neither PBCS/EPBCS support security by cube.  There is an existing enhancement request for that feature.  I suggest you create an Enhancement Request via My Oracle Support and ask to be added to that enhancement.

      The age-old workaround is to create 2 separate user IDs with access for Entities 1:10 for User1 and Entities 1&2 for User2.  If it is the same user, the extra user account does NOT count as an extra user license.  EPBCS User Licenses are based on a "Named" user.  In this case, it would be the same user but with 2 different logins.

      I hope this helps.

      • Tuan-Anh M. Nguyen

        Appreciate the response Mark as we are interested in this functionality.

        Is there an enhancement request number we can reference?

         

        Thank you.

        • Mark Rinaldi

          So these 2 enhancement requests were closed because there weren't many customers assigned to them:

          21269443 - NEED PROVISION TO ASSIGN SECURITY AT THE CUBE LEVEL INSTEAD OF  MEMBER LEVEL

          24712619 - SUPPORT CELL-LEVEL SECURITY

          You can request they be re-opened.  Cell-level only works across cubes if you  have a unique dimension per cube included in the security but it is a popular request, informally.

          If we want these, we need to see many customers requesting these enhancements... Challenge given!

          • Tuan-Anh M. Nguyen

            Thank you Mark.

          • Tuan-Anh M. Nguyen

            Mark, we have logged the two enhancement requests:

            SR 3-18270649036 : Please reopen enhancement request 24712619 - SUPPORT CELL-LEVEL SECURITY

            SR 3-18270649021 : Please reopen enhancement request 21269443 - NEED PROVISION TO ASSIGN SECURITY AT THE CUBE LEVEL INS

             

            Hopefully others will join us.

      • anisha nazrat

        Hi Mark,

        Is Single Sign On going to work for 2 logins for a single user?

        Thank You,

        Anisha

    • Tino Tarantino

      The short answer is NO. Security is not configured by module (aka plan type). .Planning security is configured by dimension  (Entity in your example).   I assume here the same entity members are shared between FS and WFP module.  Thus, if you grant access to Entity 1 thru Entity 10 in FS to FSUSER1, that same user will also have access to those entities in WFP.      I can think of two workaround, neither of which is ideal for your situation.

      1.  Separation of duties.   Users which have access to FS are mutually exclusive to those users which have access to WFP.    In this scenario, you would create two distinct security groups:   FS_PLAN_USERS (only has access to the FS module) and WFP_PLAN_USERS (only has access to the WFP module).     All users are either in one group or another, but not both.   If you need to enforce security at the lowest level entity member, then you would also need to create security groups for every level 0 entity member in your hierarchy (i.e. Entity1_USERS,  Entity2_USERS,  ... Entity10_USERS).    Assume we have two users:  FSUSER1 and WFPUSER1.  You would then assign FSUSER1 to groups (ENTITY1_USERS thru ENTITY10_USERS) and assign WFPUSER1 to ENTITY1_USERS and ENTITY2_USERS.

      2. Separation of Entity members.    If the first workaround is not an option, you can create mutually exclusive entity members by module.  For example, in addition to Entity  1 thru Entity 10 (unique to FS) , you now have  Org 1 thru Org 10 (unique to WFP).  This solves your security issue, but it also introduces a new mapping issue.  when mapping WFP expense to FS.   You can solve this mapping issue by loading in the "Financial Cost Center" (i.e. Entity 1 ... Entity 10) as a smartlist property of the employee.   Your data map can then use this new smarlist employee property to correctly map WFP expense to the correct Financial Cost Center in FS.