Moqui Framework

Moqui 2.1.0 introduced support for sub-selects (sub-queries) within view-entity definitions. This allows for more complex join logic and functional flexibility.

How to use:

• Enable sub-selects by adding a flag to a member-entity or member-relationship element.
• The query structure changes so the member entity is joined in a SELECT clause. Conditions for fields on the member entity are placed in its own WHERE clause rather than the top-level WHERE clause.
• You can use alias.@function and alias.complex-alias (e.g., using concat_ws for combined name aliases) within the sub-select.
• Sub-selects are supported even when the member is another view-entity.

Some Moqui defaults are intentionally permissive to allow specific functionality, but they should be reviewed by operators:

• Groovy Shell WebSocket: The /groovysh endpoint is enabled by default. It allows Remote Code Execution (RCE) but is gated by ADMIN_ADV and GROOVY_SHELL_WEB permissions.
• Password Reset: The reset#Password transition is configured with authenticate="anonymous-all" and allow-remote="true" to allow remote password resets.
• Email Allowed Hosts: The email_allowed_hosts setting is empty by default, meaning the system may connect to any host for polling/sending until an operator defines an allow-list.
• DataSnapshot Import: Defaults to disableEntityEca="true" so that an update via Tools can restore security-critical rows.

In Moqui 3.0.0 and later, the embedded moqui-elasticsearch component is no longer supported. It has been replaced by ElasticFacade, which acts as a client to an external OpenSearch or Elasticsearch instance.

To use it, you must install an external instance in runtime/opensearch or runtime/elasticsearch. These can be automatically managed (started/stopped) by the MoquiStart class if running as an executable WAR.

Recommended versions for v3.0.0:

• OpenSearch 1.3.1
• Elasticsearch 7.10.2 (the last Apache 2.0 licensed version)

Moqui 2.0.0 introduced the org.moqui.context.ToolFactory interface to initialize, destroy, and retrieve instances of tools (like ElasticSearch, Camel, or KIE).

To use tools, you should interact with them via the ExecutionContext or ExecutionContextFactory rather than accessing them directly.

Configuration: You can define tools in your MoquiConf.xml using the tools.tool-factory element. Components can also provide their own MoquiConf.xml to modify the tool factory.

// Using ExecutionContext to get a tool
Tool myTool = ec.getTool("ElasticSearch", Client.class);

// Using ExecutionContextFactory
Tool myTool = ecfi.getTool("Camel", CamelContext.class);

In Moqui 2.1.0+, you can use DataDocument to create dynamic view entities. This allows for flexible, data-driven query definitions.

Key behaviors:

• Any DataDocument can be treated as an entity using the naming pattern DataDocument.${dataDocumentId}.
• DataDocumentField supports a functionName attribute for applying functions to fields within a DataDocument based query.
• Note on Primary Keys: For version 2.1.0, DataDocument JSON generation no longer automatically adds all primary key fields of the primary entity to allow for aggregation. If you are using these for ElasticSearch indexing, you must explicitly define all primary key fields to ensure a unique ID is present.

<!-- Example naming pattern for accessing a DataDocument as an entity -->
DataDocument.my_custom_document_id

Moqui supports 'no sub-path' subscreens. This mechanism allows you to extend or override screens, transitions, and resources under a parent screen by searching for a specific path in each 'no sub-path' subscreen first. If the path is not found there, the system falls back to looking under the parent screen.

This is useful for resolving paths like /index.html or /Login to specific components (e.g., moqui-org) rather than defaulting to the standard webroot definitions.

Moqui 3.0.0 introduced MFA support for logins, password updates in screens, and REST APIs.

Supported Factors:

• authc code via email or SMS
• TOTP code (via authenticator apps)
• Backup codes

Configuration: You can enforce MFA by setting a flag on a UserGroup. If the flag is enabled, all users in that group will be required to provide a second factor if they have any additional factor enabled.

When establishing a WebSocket connection, Moqui 4.0.1 no longer supports authentication via the query string (e.g., ?api_key=... or ?login_key=...).

To authenticate a WebSocket handshake, you must use one of the following:

1. An existing HTTP session (via session cookie).
2. HTTP Basic authentication.
3. api_key or login_key provided in the headers.

If you previously relied on passing keys in the URL for endpoints like /groovysh, you must update your client to send these as headers.