You could probably make the type ahead filters work by using non-persistent attributes on WO but it doesn't seem like a good way to handle. I've always found the locations allowed values strange because you can reference non-operating locations (LABOR, STOREROOM, etc.). While a storeroom is typically a physical location, I think most organizations create it a second time as an operating location so that it can be reflected in the location hierarchy appropriately.
There's a crossover domain LOCATIONCROSSCI on the attribute. Adding a list where there seems to work as expected (though I only barely tested it). For example when I used type='OPERATING' it eliminated the LABOR, STOREROOM, etc. options. I wouldn't suggest changing the validation where clause, nor would I use an automation script. But adding a list where should be relatively harmless to do as it should impact lookups only.
Your type ahead values will already be cached so you would have to use an In Private window to test to make sure that works there as well but I would imagine it would.
------------------------------
Steven Shull
IBM
------------------------------
Original Message:
Sent: 11-10-2021 11:08
From: Travis Herron
Subject: Configuring Type-Ahead
The case-in-point is in Work Order Tracking, I've configured Type-Ahead on the LOCATION field to use the LocationID and Description. The Type-Ahead is working great. . .however, it is also allowing users to choose Decommissioned locations for the Work Order. I'd also like to limit it so that they can't enter a Storeroom Location either.
Is there anything I can do to configure Type-Ahead so that it won't "recommend" Locations with a Decommissioned status and/or Storeroom locations?
If not, is my only hope here an attribute Automation Script on WORKORDER.LOCATION?
#Administration
#Customizations
#EverythingMaximo
------------------------------
Travis Herron
Pensacola Christian College
------------------------------