Maximo Integration

  • 1.  Using CUSTOMCONDITION script in Security Group restriction

    Posted Thu October 07, 2021 09:07 AM

    I created a script with a launch point CUSTOMCONDITION and write only one line in the script code 
    evalresult=False

    then I created a condition expression to use this script then I go to global data restriction and create a restriction on the Locations object and use Qualified as a restrication type.
    as you see the condition will return False all the time which mean the logged user will not be qualified to see any location record, but when I go to Locations APP and display the list I can see all the list but I can't perform any change and Save due to I'm not qualified to perform any action on this record.

    the issue is, No one should be able to see any location record or see the location in the locations app List, if I do the same exercise but using a conditional expression with type expression instead of the automation, the user will be not able to see any location record.
    and one another note if I use the same script but with the hidden or read-only type it works perfectly

    My question is why in qualified restriction it doesn't work?



    ------------------------------
    Mahmoud AbdElhakiem
    ------------------------------



  • 2.  RE: Using CUSTOMCONDITION script in Security Group restriction

    Posted Fri October 08, 2021 08:47 AM
    Qualified data restrictions are special as it has to get built into the where clause to filter the data from the database. It's done for a few reasons (performance, to avoid the Maximo framework having to remove the object from the set, etc.) but the best reason is to ensure that the data isn't exposed in a report. If you ran a WO details report for example you would be able to see the records even though you couldn't view them in the UI. 

    Class based restrictions (including the automation script custom condition) have a function called "toWhereClause" that a custom class could build a SQL where clause to filter out. The ScriptCustomCondition class returns null here so it's not evaluated for qualified data restrictions on the list tab. When you're on a record the qualified data restriction is evaluated again which is why you're prevented from modifying. 

    I'd suggest opening a RFE if you'd like to be able to control this in a script. You can submit your idea here: https://ibm-ai-apps.ideas.ibm.com/ideas/

    ------------------------------
    Steven Shull
    ------------------------------



  • 3.  RE: Using CUSTOMCONDITION script in Security Group restriction

    Posted Sun October 10, 2021 02:38 AM
    Hi Steven,
    but I'm wondering why the hidden type works perfectly although it follows the same concept of qualified, am I correct?
    that makes me confused.

    ------------------------------
    Mahmoud AbdElhakiem
    ------------------------------



  • 4.  RE: Using CUSTOMCONDITION script in Security Group restriction

    Posted Mon October 11, 2021 10:29 AM
    Hidden is more like read-only than qualified in my opinion. Hidden obscures the values on the record but the record and all the attributes are retrieved and you can see it's there. Essentially when you flag an object hidden, it just tells each attribute on the object that it's hidden so it obscures the data in the UI. It's not much different than telling each attribute that it's read-only. 

    I personally don't like hidden at the MBO level because it's sometimes used mistakenly without realizing the impact. Reports don't enforce hidden restrictions (IE I can run a report against it and see the records that were "hidden" from me). Hidden at the attribute level makes more sense as you wouldn't necessarily want to show cost information for example to all users but need to allow them to see the other supporting data.

    Qualified enforces the data restriction (including in reports) by not even retrieving the records. In general (depending on the query written), it's going to be faster because it's only retrieving data you are allowed to see. It's not perfect though. It's only enforced when your qualified data restriction is on the main object of an application for example. If you're going through a relationship (such as ASSET->WORKORDER), your qualified data restriction won't be enforced. So when you provide multiple ways to see the information, you have to be careful that you don't break your qualified data restriction.

    You could request a RFE to support evaluating the class based restrictions but I don't think that is likely to be approved. The only way I think that would work is to loop through all records evaluating the class restriction and then generate a new where clause that filters the records down based on a field (such as the unique ID of the table) because enforcing the restriction in reports is critical. That would be painfully slow.

    ------------------------------
    Steven Shull
    ------------------------------



  • 5.  RE: Using CUSTOMCONDITION script in Security Group restriction

    Posted Tue October 12, 2021 02:04 AM
    Clear answer, thanks

    ------------------------------
    Mahmoud AbdElhakiem
    ------------------------------