Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
1 reply Latest Post - ‏2013-05-08T10:50:51Z by Dave_Ward
SystemAdmin
SystemAdmin
35 Posts
ACCEPTED ANSWER

Pinned topic Best way to implement access control rules In IBM Case Manager Client

‏2013-03-26T04:54:19Z |
We are building an IBM Case Manager Client application using the out of the box case data widgets (text fields, drop down choice lists, check boxes, radio buttons, etc). Each user role can have a different access control rule for a given field. For example, "Administrators" is allowed to create, view, update or delete a value for a particular text field that is tied to a case property such as "root cause". A "General User" on the other hand can only create, view or update a value into the same text field.

What approaches are there to implement field level access control rules -- where the rules vary by user user role -- using the IBM Case Manager client and its set up of widgets ? Are there any out of the box solutions ? If that is not the case, which solutions involve the least amount of custom coding ?
  • Dave_Ward
    Dave_Ward
    38 Posts
    ACCEPTED ANSWER

    Re: Best way to implement access control rules In IBM Case Manager Client

    ‏2013-05-08T10:50:51Z  in response to SystemAdmin

    Hi,

    I have implemented something similar in Work Details pages by doing the following high level steps (ICM 5.1.1):

    - Disable Send Case Information broadcast event in Command widget
    - Wire a Script Adaptor between the Command and Properties widget using the Send Case Info events
    - In the script Adaptor do the following:
        - Get the Roles the current user belongs to using the BPM REST API
        - Determine what field level permissions this user has based upon their Roles.
            - For Prototype you can hard code the logic in the Script Adaptor
            - In Production you might want to develop a custom REST API and have the Script Adaptor call it. The REST API can then get the field configuration data from a DB, etc.
        - Amend the payload to disable / hide certain fields based upon the users Role
            - payload.caseInfo.caseData.XYZ_MyField.isHidden = true    <=== Hidden
            - payload.caseInfo.caseData.XYZ_MyField.required = true    <=== Required
            - payload.caseInfo.caseData.XYZ_MyField.updatability = "readonly"    <=== Read Only
            - Take a look at the Infocenter for more details on the payload structure or use console.log (payload); to dump out a working payload to Firebug
        - Return the amended payload to the Properties widget

    From your description above where you say create / update / delete values, I'm guessing that you are talking about arrays of values here. I haven't tried this technique with arrays but would be interested to know if you get it working. I wonder if you can use the technique on individual elements, or whether it only works at entire field level?

    I don't really like using the built-in array control anyway as it is not very functional and does not work where you need to have multiple array fields linked together (i.e. FirstNameArray, SurnameArray, etc.). In these scenarios I normally hide the arrays using the "isHidden" property and then use a custom widget to just display the required array fields. You can then pass the updated values back to the fields in the Properties widget by using the UpdateDependentProperties event / payload. This has got to be easier than thinking about totally re-writing the Properties widget.

    Also, have you considered using Forms to provide this sort of functionality.

    Good luck!

    Dave.