AnsweredAssumed Answered

approve role B as role A subcomponent

Question asked by Zoltan Izsak on Sep 16, 2019
Latest reply on Oct 2, 2019 by Frank Schubert

Like • Show 0 Likes0
Comment • 3

I am preparing a role A which has role B as subcomponent. I would like to get approval from role B business owner to add it to role A. However when I add "dynamic - role owner" to approval node as approver it is resolved to role A business owner instead of role B business owner.

Also if I add a group C as well as subcomponent then the "object - group: owner" is resolved to group C owner. Unfortunately there is no "Object - Role: owner" choice, only "Object - Role: Last Reviewed Date" and "Object - Role: Name".

Has anyone any idea how to overcome this issue? Is there any best practice?

No one else has this question

Outcomes

3 Replies

Frank Schubert Sep 19, 2019 3:10 AM
Mark Correct
Correct Answer
Yes, I've been there. It is not super easy to solve it but I've managed using splits into custom categories. I am not sure if you are familiar with these. There is a public function in the database that lets you define and assign a category using whatever logic you want to implement. My approach was to give the category of Owner:Backup_owner to each indirect role in a request. then call a sub-workflow that splits the request per category. Items that don't have a category don't get processed (those would be your direct roles/modified roles and other objects that are not roles...) and the ones groups by a common category (in my case the owner:backup_owner tuple). Then in the sub flow I grabbed the category and split the values into owner and backup_owner so I can assign the approval to those (build-in variables don't work as they refer to, as you've found out, not the right set of owners).
I split by owner:backup_owner as only splitting by owner could be problematic if you do need a backup_owner in there. And then the edge case of roles being owned by the same owner but different backup-owners would lead to the wrong assignment.
1 person found this helpful
Like • Show 2 Likes2
Actions
- Zoltan Izsak @ Frank Schubert on Sep 23, 2019 5:36 AM
  Mark Correct
  Correct Answer
  Let me have some specific questions, unfortunately there are some grey areas:
  
  Which function you mean? I can see the following in db:
  
  Is this role category a general role attribute (so you can see it t_av_roles) or is it related somehow to a CR?
  How do you decide if a cri is direct or indirect role?
  
  Anyways, I like very much this technical approach and I am glad that there is a working solutions for a legitimate business case.
  Like • Show 0 Likes0
  Actions
  - Frank Schubert @ Zoltan Izsak on Oct 2, 2019 4:20 AM
    Mark Correct
    Correct Answer
    All doable, all done before.
    
    As a general remark, if you split by a category and have a sub flow that splits then by that category ONLY CRIs (change request items) that HAVE a category will get processed by any instance of the subflow. That can come in super handy as you then only provide the items for approval that are relevant for those approvers.
    Also, depending on your use case you may need to do several splits after another. So split by one category, start the approval sub flow, come back up, split again differently, sub flow again and so on. This makes it possible for the sub flow definition to be one and the same for all those different approvals, it just gets presented he CR in different slices and in turn puts those in front of the different approvers.
    
    Let's say you want to do a split for the role_owners:backup_owners in a CR for the INDIRECT roles, so the roles contained within roles that directly get assigned.
    You need to
    a) prep the split
    b) start a sub flow that splits by "category"
    
    for a) prep the split
    In the below example we "group" each CRI (change request item) that is of type "GlobalRole" and that gets added or part of a role create. You could of course remove that part of the WHERE clause to include all kinds of entitlement types. The OPERAND in a CRI is the element that gets modified and the VALUE is what is happening to it. In the below example you would provide the owners:backup_owners of the INDIRECT roles (we select the VALUE_TYPE GlobalRole) their elements (their global roles) for approval.
    
    DECLARE
    v_request_id number;
    BEGIN
    select to_number(nvl('${access_request_requestID}',0))
    into v_request_id
    from dual;
    avuser.ACCESS_REQUEST_PUBLIC.SET_CHANGEITEM_CATEGORY
    (
    v_request_id,
    'GlobalRole',
    NULL,
    'SELECT CRD.VALUE_ID as ID, UE.OWNER_ID||'':''||UE.BACKUP_OWNER_ID as CAT
    from avuser.PV_CHANGE_REQUEST_DETAIL CRD INNER JOIN avuser.t_av_roles UE ON UE.NAME=CRD.VALUE_NAME
    WHERE CHANGE_REQUEST_ID=' ||${access_request_requestID}||'
    AND VALUE_TYPE=''GlobalRole'' and (REQUEST_TYPE=''Add'' or REQUEST_TYPE=''Create'')',
    true
    );
    END;
    
    b) inside the sub flow you need to deconstruct the split criteria
    (which we so cleverly set as the owner:backup_owner in the previous step)
    
    select substr('${jobUserData_acmx2ExJobGroup}',1,instr('${jobUserData_acmx2ExJobGroup}',':')-1) as backup_owner_id, substr('${jobUserData_acmx2ExJobGroup}',instr('${jobUserData_acmx2ExJobGroup}',':')+1) as roleownerid from dual
    
    Use these two workflow variables (job level) to assign the approval task to. The cool thing here,
    
    If you want to split differently, have a look at this:
    
    Split by the "target" role, or the direct role (for role management request, we use the role versions here...).
    Similar to above, but now we are looking at it from the OPERAND, so at the role that got modified.
    DECLARE
    v_request_id number;
    BEGIN
    select to_number(nvl('${access_request_requestID}',0))
    into v_request_id
    from dual;
    avuser.ACCESS_REQUEST_PUBLIC.SET_CHANGEITEM_CATEGORY
    (
    v_request_id,
    'GlobalRoleVersion',
    NULL,
    'SELECT CRD.operand_id as ID, UE.OWNER_ID||'':''||UE.BACKUP_OWNER_ID as CAT
    from avuser.PV_CHANGE_REQUEST_DETAIL CRD left outer JOIN avuser.t_av_roleversions UE ON UE.roleversion_id=CRD.operand_ID join WHERE CHANGE_REQUEST_ID='||${access_request_requestID}||'
    AND crd.OPERAND_TYPE =''GlobalRoleVersion'' and crd.REQUEST_TYPE =''Add'' and crd.derived_type=''Direct''
    ',
    true
    );
    END;
    
    Split by target role owners:backup_owners but display the the user members only for approval:
    Here the OPERAND are the Users that get added.
    
    DECLARE
    v_request_id number;
    BEGIN
    select to_number(nvl('${access_request_requestID}',0))
    into v_request_id
    from dual;
    avuser.ACCESS_REQUEST_PUBLIC.SET_CHANGEITEM_CATEGORY
    (
    v_request_id,
    'User',
    NULL,
    'SELECT CRD.operand_id as ID, UE.OWNER_ID||'':''||UE.BACKUP_OWNER_ID as CAT
    from avuser.PV_CHANGE_REQUEST_DETAIL CRD left outer JOIN avuser.t_av_roleversions UE ON UE.roleversion_id=CRD.value_id WHERE CHANGE_REQUEST_ID='||${access_request_requestID}||'
    AND crd.OPERAND_TYPE =''User'' and crd.REQUEST_TYPE =''Add'' and crd.derived_type=''Direct''
    ',
    true
    );
    END;
    
    That's pretty much it.
    
    Frank
    Like • Show 0 Likes0
    Actions

approve role B as role A subcomponent

Outcomes

for a) prep the split

b) inside the sub flow you need to deconstruct the split criteria

If you want to split differently, have a look at this:

Related Content

Recommended Content