moqui | For the latest see | Machine Learning library

There is no consistent boolean data type across different databases so to remain relational database agnostic Moqui uses a single character column with the text-indicator entity field type. The convention in Moqui Framework and the business artifacts in Moqui Ecosystem is to use Y for yes/true and N for no/false.

Digging deeper, in EntityDataLoaderImpl.groovy we have:

You are correct that OrderPart and OrderItem are similar in a way, they are both detail entities to the OrderHeader master entity. For general info on master/detail and other data model patterns see:

https://moqui.org/m/docs/framework/Data+and+Resources/Data+Model+Patterns

For more specific information about the Order data model see:

https://moqui.org/m/docs/mantle/Mantle+Structure+and+UDM/Order

The use of OrderItem and OrderPart are very different, items being the line items for the order and parts being a break down of the order under OrderHeader to allow for shipping to multiple locations on the same order, or any other business requirement for splitting orders. Order Parts are used in different ways in different companies as a generic model but you can get an idea of the fields that are intended to be different for different parts of an order by looking at the fields on OrderPart vs OrderHeader.

If the transition exist and the user has permission to access it, then all fields disabled is a bug, please report it by create a issue.

On moqui-conf.entity-facade.datasource there is startup-add-missing attribute that takes the value from default-property 'entity_add_missing_startup'. So in short add this entry on MoquiDevConf.xml and MoquiProductionConf.xml:

This looks like a ClassLoader issue. In order to support runtime additions to the classpath Moqui uses a custom ClassLoader that supports this behavior, including the 'classes' and 'lib' directories under the 'runtime' directory or in component directories. The custom ClassLoader (MClassLoader) is set as the context ClassLoader for each thread within the servlet container or threads created internally for Moqui background jobs, etc.

The most likely reason this happens with KIE 'mvel' scripts is that it does not use the current thread's context ClassLoader (ie the mvel compiler isn't using it) or it is running in a thread not initialized through Moqui Framework so the thread's context ClassLoader is not set yet.

The first step to fix this would be to research classloading options for the mvel compiler. There may be a file where it is configured but it is more likely an API option that is needed, perhaps to specify the ClassLoader explicitly so it uses the thread's context ClassLoader. If you want help pursuing that it isn't really a question any more and doesn't belong on StackOverflow. The Moqui community collaboration resources available are described on the Moqui web site here:

https://www.moqui.org/m/docs/moqui/Community+Guide

Checkout https://www.moqui.org/m/docs/framework/Security#artifact-authz

The following text is copied from Moqui documentation.

The first step to configure artifact authorization is to create a group of artifacts. This involves a ArtifactGroup record and a ArtifactGroupMember record for each artifact, or artifact name pattern, in the group.

For example here is the artifact group for the Example app with the root screen (ExampleApp.xml) as a member of the group:

Business requirements are difficult to design for without detail and context, but it sounds like what you really want to model is not at the Asset level but at the Product level. For asset type products the Product and related entities (like ProductAssoc) are used to define characteristics of physical items, Asset records represent the actual physical items.

One example of this is the maintenance side of things. The maintenance schedule is part of the Product definition (applicable to all assets for that product) and the maintenance history is part of the Asset side of things (applicable only to specific physical items).

As of the last release of Moqui (2.1.1) and in the current GitHub code this is supported. The NotificationTopic entity has a emailTemplateId where you can specify the EmailTemplate to use for notifications on that topic. There is a simple OOTB EmailTemplate for notifications with emailTemplateId "NOTIFICATION" (defined in the MoquiInstallData.xml file).

The other side of this is the per-user configuration of whether to receive email for notifications on a given topic. The is stored in the emailNotifications field of the NotificationTopicUser entity. This can be set by users in the My Account app on the Notifications screens, or in the System app on the User Account screen.