Problem’s Reason:
To actually find a party, you need to type in the exact party id (see searchPartyList transition) or type in identifying information for a party with a roleTypeId:'Customer,CustomerBillTo,OrgInternal'. There’s no obvious information about what you need to do especially when the search cache hasn’t updated (which is why I created this in the first place).
Solutions:
Have field display some text in the field before typing anything telling the user what to type in
Have similar information to #1 displayed somewhere else
Are you saying that in the system you are testing with that there is no ElasticSearch server, or that somehow it is now up to date? If so, that’s something the code can’t do much about, that’s more of an administrative thing because all of the Party search & selection across all applications use ES searches for more flexibility (these days anyway).
You are correct that even if ES is there or doesn’t have the data you can still specify the Party ID to get it to work. This is not the intended way for it to work or to be used, ES really is necessary and it needs to be up to date… so the question is what’s going on with ES on this instance?
There was an OpenSearch server there. I looked at the index that was being searched, but the data for the party with a role hadn’t been loaded despite it being set in the database. I thought it might be OpenSearch, so deleted the OpenSearch folder and downloaded ElasticSearch. After running it with ElasticSearch the data was loaded. I then deleted ElasticSearch and re-downloaded OpenSearch, ran it, and the data was loaded.
I’m not sure if it was something like the DataDocument not loading in time or a bug with OpenSearch, and I’m sure how much of a problem it really is. Is it common to have DataDocuments not loaded within seconds or minutes?
Sending data documents to ES is done on transaction commit… as long as the DataDocument and DataFeed data is in place at the time of commit. My guess would be that either some data loading went awry, or perhaps OpenSearch was not running or was having other issues when the data was initially loaded.
For future reference, if anything like this happens you can manually re-index data by DataFeed in the System app. The button is Feed Index inside the Data Documents and Feeds box. There is also a screen for searching there with a button to open a dialog to view the actual JSON text from Elastic/OpenSearch, which is a good way to test and review data.
This sounds like an environment specific issue. My production instance is working fine and I also checked Moqui demo which gives expected behavior. However there is some good information for future readers.
Side note, it has been a while since I setup a new client and project in HiveMind but I do recall having some issues if things weren’t setup in the right order, particularly around rates.
FWIW, H2 does use transactions and generally this works just fine.
The main thing I’d wonder about in a situation like this is what the Moqui log says… are there errors about not being able to contact Elastic/OpenSearch? are there any transaction or query or other errors?
In general the first place to look is the logs because the UI is not designed to show every detail, and everything that happens with DataFeeds sending data to Elastic/OpenSearch happens in the background so there is nothing to see in the UI as it happens.
Thanks for the comments. I’m honestly not sure what the problem was. If I run into it again, I’ll be sure to do more research into why. However, for now, it’s not really worth looking into more deeply.