Hello,

I've stumbled upon an interesting issue related to conditional expression logic in Maximo. In Maximo desktop you can define a conditional expression for a specific value in WOSTATUS domain to restrict when certain status is available for users. For example, you can restrict certain status to some user group or to be available depending on some work order details. This works perfectly fine in Maximo desktop but not in Maximo Mobile. So in Mobile Technician application the conditional expressions are ignored and it seems to be possible to change the work order status to any value.

I've found a nice article from Maycon Belfort on how to conditionally filter statuses in Maximo Mobile - Episode 3: Changing Status in Maximo Mobile

However, this means duplicating the logic of conditional expressions defined for the domain.

Is it possible to enable conditional expressions to be used by Maximo Mobile as well? I assume it should be possible by adding custom JavaScript in AppCustomizations.js. Has anyone solved it so far?

Writing something that works 100% of the time is impossible. I'm not a fan of conditions on WOSTATUS even for desktop Maximo use cases but I'll keep this focused on why this is a problem for mobile.

The most common problem is conditions that depend on data that you don't have the device. For example, I've seen a lot of conditions that has a query like:

exists(select 1 from groupuser where userid=:USER and groupname='MAXADMIN')

Since we won't have that data out of the box, even if you tried to evaluate it on mobile, you couldn't without also writing logic to find and download this data. For something like group membership specifically, that's not too bad. But there could be other queries that hit larger tables like WORKORDER that would require downloading excessive amounts of data. 

That also ignores the condition types of java class & automation scripts that can't be executed on a mobile device at all for obvious reasons.

Your "best" option is to break offline use of the app. There's an allowedstates attribute in the REST API that you can include on the WO datasource that would show all allowed statuses Maximo would let the record go to. The important part is this is only accurate for when the WO was synchronized. If the record has changed in any way, such as someone changed the status to INPRG or reported labor, that list is no longer accurate. You would need to call a forceSync on that WO to fetch all the WO data again from the server.

The problem with that is the user experience could be very poor because they're waiting on this data retrieval from the Maximo server. And if they don't have connectivity, you either need to prevent status changes or behave differently in online/offline mode which we intentionally try to avoid in our applications. 

Hi Steven,

Thanks a lot for sharing your knowledge. It's quite insightful.

While the suggested direction is clear, I've got more questions about the details. Specifically, I'm still figuring out how to handle the offline/online modes of the app. I know how to add an extra attribute on the datasource but I'm not sure how to correctly use forceSync. Also I understand that due to breaking the offline use I need to make some extra checks in the code to either show an error message or use some graceful workaround. If there is any example of this approach, it'd be highly appreciated. I see relevant code in pageResumed function of WorkOrderDetailsController.js:

if (this.page.state.disConnected && this.app.state.networkConnected
  && this.app.state.refreshOnSubsequentLogin !== false) {
  await woDetailResource.load({
    noCache: true,
    forceSync: true,
    itemUrl: page.params.href,
  });
  this.page.state.disConnected = false;
}

You're in the right direction with how to trigger a forceSync of a single record. I would not utilize pageResumed because that will happen much more frequently than status changes and we don't want this to fire often given the impact of it. Off the top of my head, what I think I would do is this:

I would add my own status tag to the WO detail page. When that is clicked, I would have it hit a method I added to AppCustomizations that would call the forceSync on the WO datasource and call the out of the box methods on the page like openChangeStatusDialog on the Schedule Page. Then I would have an onAfterLoadData for the JSON datasource to remove any values not in the allowedstates. The example I built a while ago isn't using allowedstates but walks through what I'm thinking: https://community.ibm.com/community/user/asset-facilities/viewdocument/maf-configuration-application-fil?CommunityKey=3d7261ae-48f7-481d-b675-a40eb407e0fd&tab=librarydocuments

It's not the best because there's a small period of time that invalid statuses could be displayed until after they're removed in the onAfterLoadData. But we don't want to replicate all the logic involved with status changes and if we don't call the out of the box methods like openChangeStatusDialog, various state variables we need wouldn't be set unless we set it ourselves. That's difficult to maintain so I went with the path of least resistance here. 

if (this.page.state.disConnected && this.app.state.networkConnected
  && this.app.state.refreshOnSubsequentLogin !== false) {
  await woDetailResource.load({
    noCache: true,
    forceSync: true,
    itemUrl: page.params.href,
  });
  this.page.state.disConnected = false;
}