Is it possible to have different edit/create rcdc forms for different set of administrators for the the same object type e.g.User? RRS feed

  • Question

  • What I am wondering is whether we can arrange people in Administrators set to have one RCDC edit USER form (e.g. some attributes are drop down controls)

    and lower-lever Admins, those in say FirstLevel-Admins set get to see a different RCDC form, when editing User objects (and those attributes may be ReadOnly textboxes with fixed values.)

    i.e. same type of object: User, just a different form is used based on Set membership.

    The documentation is great describing how to modify the RCDC form but not so great at describing how to use it and whether different sets of people can see different forms.

    I understand that via the MPRs and Sets we can select which users a FirstLevel Admin can see and modify etc.. but they seem to use the same form as a Top level Administrator, or the Top Level Admins get the same edit user form as developed for a lowerlevel Admin. I think this might not always be desired.

    Wednesday, February 20, 2013 6:43 AM

All replies

  • Wednesday, February 20, 2013 7:21 AM
  • Out of the box FIM RCDCs only work on a 1-1 basis per object class (i.e. 1 for each of view/create/edit).  Everything else is a work-around.  However, reading your first paragraph I don't really understand why you can't still get this working with a single RCDC, since if a person only has read access to a given binding then the drop-down control will not be rendered and a read-only control will take its place.  Is this all you need?

    If this is NOT what you are after, then Tomasz talks about one work-around possibility ... but the end result will have draw-backs as he says, and ultimately I agree with him when he says you're most likely going to want to create your own FIM UI for this.

    There is at least one other way to think of this which I have used myself ... same RCDC but different tabs per user set.  This works on a per-attribute basis ... if you want to hide an entire tab from a set of users, then this can be achieved at the binding level - i.e. if none of the bindings on any given tab are visible to a user then they won't see the tab at all.  You could extend this idea to allow certain users read/update access to completely different bindings on a user, and in the AuthZ step copy these values to the "real" bindings on submit, allowing an approval phase.  This may be off track, but it is a way of working within the constraints of the RCDC model.

    Bob Bradley (FIMBob @ ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 12:14 PM
    Wednesday, February 20, 2013 10:50 PM
  • I faced a similar implementation problem once.

    As the clients requirement was to populate different values in the drop down for users with different departments. According to the current FIM 2010 Architecture this is not possible.

    So what i did was to create multiple custom attributes with multiple drop-downs in the RCDC (luckily the drop down only had a few items-  so i ended up with four such attributes and drop downs) and then controlled through the MPR which department had access to which custom attributes and in the MPR i used an action workflow which updated the actual attribute through the function evaluator workflow activity.

    You can use something similar.

    Regards Furqan Asghar

    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 12:14 PM
    Thursday, February 21, 2013 1:23 PM