Searching based on who created a record

Technical Questions
1

I don’t see created/updated fields on entities. What is the best way to identify records based on who created or last updated?

1 Like
2

Hi.

Coming from the corporate/enterprise CRM world of Amdocs/Clarify/PeopleSoft I was a bit taken aback when I started looking at Moqui’s data model.
I was, kind of, expecting a generic createBy/lastUpdatedBy pairs on ‘workflow’ related entities (Orders, Requests, Tasks/WorkEfforts).

I think Moqui is a bit more on a case by case basis. For example, the filedByPartyId field specifically identifies the creator of a Request.

I guess you could infer who created and last updated an entity if it is flagged as audit-logged. But the amount of historical data generated and the processing needed to go through it may make this option a bit more tedious than it should be (since you only really need the first and last audit log entries).

In hopes that I understood your question.
Regards

3

I meant audit-trailed rather than audit-logged.

4

There is already a lastUpdatedStamp field in each entity. You may extend the entity add createdStamp and createdUserId by the folloing code.

<extend-entity entity-name="WorkEffort" package="mantle.work.effort">
    <field name="createdStamp" type="date-time" default="ec.user.nowTimestamp"/>
    <field name="createdUserId" type="id" default="ec.user.userId"/>
</extend-entity>
2 Likes
5

Hi.

How would it work for a 'lastUpdatedUserId" ?
Unless explicitly set, wouldn’t it be set at creation time (like createdUserId) and never updated?

Rgds.

6

I implemented it by the following code.

<eecas xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://moqui.org/xsd/entity-eca-2.1.xsd">

    <eeca id="WorkEffortSetChangedByUserId" entity="mantle.work.effort.WorkEffort" on-update="true" run-on-error="false" set-results="true" run-before="true">
        <actions>
            <set field="changedByUserId" from="ec.user.userId"/>
        </actions>
    </eeca>

</eecas>
1 Like
7

Hi.

Yes, eeca was what I thought you would end up using.
You might as well use an eeca on creation also, so you have a unified solution.
In my mind eecas were used more for coarse business logic operations but, indeed, it’ll work …

We could provide this functionality as an entity definition attribute where it makes sense.

Rgds.

8

Please correct me if I’m wrong, but essentially you want something like a low-res version of the entity audit log, where you only know who changed an entity last and when?

Because if you would like to see who changed what field, when, from which old to which new value, what the artifact stack was at that time, etc, you would use the enable-audit-log attribute for each field you want to follow (or at once for the whole entity) and look at the moqui.entity.EntityAuditLog entries.

9

@jenshp correct I am not looking for full audit log, just the usual created/updated stamps for user and date-time.
I did think about audit log but may be overkill for what I need. Also not sure how to use it to determine when a record was created. Maybe that would just be the first entry in the log for a given entity and pk?

10

The intention for data history is meant to be more granular with the per-field audit log. This is the reason that created/updated by/when sorts of fields on each entity.

This is reflected in the UI with a display of things like a full status history. For created dates an entity needs to have at least one field with enable-audit-log=“true” (enable-audit-log=“update” only creates records when a value has changed so it will not have a reliable EntityAuditLog record for create). For most transactional entities in Moqui this is on the statusId field and an audit log on statusId provides much more information than a created/updated by/when set of 4 fields ever could.

Think of it this way: the Moqui Mantle Universal Data Model is intentionally denormalized, even down to things like this where having multiple records is preferable to having multiple columns… far more flexible and useful, at the cost of being more complex.

FWIW, over the years I’ve become more and more convinced that with business software flexibility overkill is rare as a problem, the opposite (low flexibility, over-simple) is much more commonly problematic.

1 Like
11

Wouldn’t it be better to do a partyId here? I can’t think of a reason to isolate this just to parties who have user accounts.

12

The general idea with UserAccount vs Party is that a user interacts with the system and a party is an abstract concept for any person, organization, automated agent, etc. To build on that distinction the framework knows about users, but does not know about parties which are defined in mantle-usl.

There are two main reasons that EntityAuditLog has a userId and not a partyId: only users can interact with the system (if a party has a UserAccount, then that user interacts with the system), and the framework only knows about users so also tracking a partyId (if the current user has a partyId) so some sort of framework plugin accommodation would need to be created to support it.