Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only
Back to discussions
Expand all | Collapse all

Classifications application: Editing CLASSUSEWITH table window records doesn't modify CLASSSTRUCTURE record

  • 1.  Classifications application: Editing CLASSUSEWITH table window records doesn't modify CLASSSTRUCTURE record

    Posted 11/11/21 09:11 AM
    Edited by System Admin 03/22/23 11:51 AM
    MAM 7.6.1.2:

    Classifications application:
    I've noticed when I edit the records in the CLASSUSEWITH table window, the CLASSSTRUCTURE record doesn't get modified.
    • That's relevant because I'm trying to figure out how to populate a custom CLASSSTRUCTURE.USEWITH_CONCAT field via an autoscript. A sample value would be: 'SR, WOACTIVITY, WORKORDER'.
      I had assumed if I added or deleted a CLASSUSEWITH record, that my script would fire - since it has a CLASSSTRUCTURE object launch point (on-save). But that assumption was incorrect. I think the launch point needs to be on CLASSUSEWTH.

    An unrelated comparison:
    WOTRACK and the LABTRANS table window seem to behave differently. If I edit the records in the LABTRANS table window, the WORKORDER record does get modified. And a WORKORDER object launch point would get fired.


    I had expected the Classifications application to behave the same way that WOTRACK does. But clearly it doesn't.
    Would someone be able to explain the reason why the two applications behave differently? Is it simply because when we edit the LABTRANS table window, the ACT… fields in WORKORDER get updated? (by Java?)

    Thanks.
    #Maximo
    #AssetandFacilitiesManagement


  • 2.  RE: Classifications application: Editing CLASSUSEWITH table window records doesn't modify CLASSSTRUCTURE record

    Posted 11/14/21 08:15 PM
    You've got the right answer User1971. In the case of LABTRANS updates, there are fields in the corresponding WORKORDER that get updated, and therefore WORKORDER launch points are triggered. When you update the CLASSUSEWITH there is no corresponding update in the CLASSSTRUCTURE object, hence the behaviour you are experiencing.

    Could you have that as a non-persistent field instead? Then you would be able to simply calculate its value upon field initialization instead of worrying about keeping it up-to-date. If that's not an option and you do go ahead with a CLASSUSEWITH launch point just make sure you get the CLASSSTRUCTURE object via the right relationship (most likely the owner of CLASSUSEWITH in your case) in order to avoid "record has been updated by another user" errors.​

    ------------------------------
    GABRIEL DIAS CESARIO
    Managing Consultant
    IBM
    Melbourne VIC
    ------------------------------



Related Content