Moqui 4.0 Initiative and PRs

Technical Discussion
61

Locally, all our components being tested are on the upgrade branches(except for @schue’s new moqui-mcp, which is starting out on upgrade).

62

I am happy to report that the framework seems to work perfectly with all tests passing on Java 25 as well. So Java 21 should be the minimum version, but we can jump versions (so far) without issues.

We are completing testing on our side, but I think the update is complete with the latest fixes to tests.

1 Like
63

I completed tests on internal projects and I can confirm the following so far:

  • Transactions with multiple tests for race conditions.
  • Basic user interface and various screens on different render modes.
  • Elastic search works fine. Logs are a little more verbose, but in proper order.
  • Tested with multiple databases, postgres and H2. In both cases unit tests are passing.
  • Security system intact with identical behavior after shiro upgrade.
  • CSV and XSL exports are working.
  • Sending emails work.
  • PDFs and printouts.
  • Job Scheduler running on cron schedule.

At this stage and after all the feedback in this thread I feel good enough to say we can go ahead with a release from my side. We might need to version the components, but that’s easy to do on later commits and after we decide on a numbering system for these components, maybe a simple 4.0 for all of them as well? Anyway, all green my side.

64

Thank you for these contributions, @Taher. I don’t know if this new post brings you something valuable, but just in case… Reverse Engineering Your Software Architecture with Claude Code to Help Claude Code – O’Reilly

65

One minor PR to default to UTC in default conf file to allow running docker services without issues @michael

I expanded that PR to remove port from being in the entry point, instead move it to command. This way we can issue commands against the moqui image like “load” and “help” instead of just running. This is necessary to have a robust way of loading data.

66

I have found another aspect that needs intervention when upgrading, due to changes in groovy. Groovy 3 introduced the safe indexing operator ?[], which avoids a NullPointerException when accessing elements in collections, just like the ?. operator does for plain classes.
So, while in moqui version 3 the expression [ownerPartyId:activeOrgId?[activeOrgId,'_NA_']:null] used in several entity filter filterMaps, in moqui v4 that expression generates an error when being evaluated whenever activeOrgId is defined.

I have created a pull request (fix: avoid ambiguity in groovy expressions between safe indexing operator by jenshp · Pull Request #217 · moqui/mantle-usl · GitHub) that fixes this expression in the entity filter definitions in mantle-usl, but there might be other similar cases.

1 Like