The condition approach tied to domain values that Subhransu mentions is what most customers use to filter statuses. You're trying to get a condition to evaluate to true when you want it to be displayed. If you have multiple conditions we'll stop evaluating as soon as we get a match (all do not need to evaluate to true for the record). And you want these to be efficient conditions so use substitution variables like :&APPNAME& as much as possible. We try to evaluate the condition in memory when possible, then query dummy_table, then query the underlying table. If your condition is like wonum='1234' we'd try to evaluate in memory and fail, then query dummy_table which will fail because there is no wonum column on the table, then we'll query the table (workorder) like select count(*) from workorder where wonum='1234'.
I bring this up because I've seen people screw this up and do something like siteid='BEDFORD' and worktype='PM' instead of :siteid='BEDFORD' and :worktype='PM'. This results in a very different query because we will query to see if any record in the database has a site of BEDFORD and a work type of PM. We won't be confirming that the current record has those things.
For this specific scenario, also remember :&APPNAME& will NOT always be set. Think mobile applications, integrations (including REST API like work centers), etc. Make sure you handle null/empty strings as well.
You could use a retrieve list automation script on the WOCHANGESTATUS.STATUS attribute but it would take over all logic. You can't just use to filter values after the fact which makes it not a good choice.
In the latest MAS release we've added some hooks for automation scripts to interact with bean class events. I haven't had a chance to test it and it's not documented yet (it'll get posted here https://ibm-maximo-dev.github.io/maximo-autoscript-documentation/ when it is) but it could possibly solve this in the future when you get to that release.
------------------------------
Steven Shull
IBM
------------------------------
Original Message:
Sent: 04-25-2023 19:08
From: Pankaj Bhide
Subject: Restricting work order status to "change work order" dialog for cloned work order app
Hello,
We have a unique requirement of hiding a few work order status values from the cloned work order tracking app (please note that they don't want to it globally - but only for the cloned work order tracking app).
Previously I handled this using a custom java class for example:
In that class I did the following:
public class LBLWOChangeStatusBean extends psdi.webclient.beans.workorder.WOChangeStatusBean
{
public MboSetRemote getList(int nRow, String attribute)
throws MXException, RemoteException
{
String strAppname=this.sessionContext.getCurrentApp().getApp();
if (strAppname.equalsIgnoreCase("WOTRACK") ||
strAppname.equalsIgnoreCase("FACWOTRACK"))
{
MboSetRemote currentList=super.getList(nRow,attribute);
Now based on the criteria specified by the user, I filtered the contents of "currentList" and returned the "currentList" to "getList" method.
return currentList;
}
We are now in the cloud and our cloud provider may not like us to have any java customizations.
Any clue/hint or advice on accomplishing the same using the automation script or anything similar?
Please help.
#Customizations
#WorkManagement
------------------------------
Pankaj Bhide
Berkeley National Laboratory
------------------------------