Maximo Open Forum

When you define the lookup-map, you should use datasource or name, never both. name is a special reference to the JSON file you alluded to that defines what is in the lookup-map. When you want a datasource that you have defined in your application, you will NOT utilize a name. 

invbalduedate is not a datasource I see in the out of the box app.xml. I bring this up because you need to make sure you define this type of lookup datasource with the same object structure and saved query as used in the other applications. You cannot have a saved query in TECHMOBILE that uses one query and another in ICMOBILE for example. That's not causing your current problem but it's another mistake I see people make often so I wanted to call it out. 

Hey Steven,

Thank you for the information! I've made some more changes, but I still think I'm missing something. I reviewed the comments that you left in the IBM post that I linked as well as your comment here, and I believe I'm closer.

Based on the IBM thread, I thought it appropriate to add in a maximo-datasource-override as follows:

I left it very "barebones", as I'm not quite sure what options are appropriate here. It is my understanding, though, that this will allow us to reference this datasource within this application without affecting other applications that utilize this datasource. This is desirable behavior!

I also changed the lookup-map to *only* make reference to the datasource, as recommended. It now appears as follows:

I chose to have it reference the "duedateFilter" datasource, as that is what appears to have been done within the IBM article, as shown below:



However, despite these changes, my filter screen still appears to only show the "Bin" and "Lot" filters as options (same result as in the original post.)

If you need any more information or context, I'm more than happy to share. Thank you for your time, it is greatly appreciated. :)

Sorry, I missed at first glance that you were trying to add a filter to the dates. In 9.1 filtering based on dates, numbers, YORN, etc. without needing lookups was added. For a date field, this is what you need because you're going to have hundreds if not thousands of distinct dates that you'd need to select. You really want to search for a range such as the nextphycntdate is between 10/01/2025 and 11/01/2025 for example. This is what the enhancement in 9.1 added. 

There were issues where anything that was not an ALN data type didn't work as a filter. For example, I tried to add a filter to a YORN attribute and was able to get it to display but couldn't get it to work. Shortly before I left IBM, the priority (which is a numeric filter) was approved as a defect Known Issue: DT424109 but I'm not sure if they extended it to other non-ALN data types. 

I tried really quickly to test the date and got it to display as a filter in the web preview, but it failed when I selected the date. 


Also, you don't want to create a filter datasource using the maximo-datasource-override on transactional datasources. It's hard to explain in text form but transactional datasources are tagged with the application and datasource that downloaded them. For example, if you had a datasource called A in the application ICMOBILE, it would tag each INVBALANCES record with ICMOBILE-A. If you create a datasource override called B, that record needs to be downloaded a second time in order to tag it as ICMOBILE-B.

Lookup datasources are only downloaded once using a single saved query and then can be accessed by any datasource. There is not the concept of tagging the application & datasource like you would have on transactional data. You can use mobile-qbe-filter and such to reduce it to the specific records you're interested in, such as filtering assets to only those that match a specific itemnum for example. But it all occurs device side rather than server side.

While your example above & the example I called out on the assetLookupDS look very similar, the behavior is very different on mobile and should be avoided.