nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Update rule executed before create (inbound) rule when moving node in share web ui

jan-prochaska

Dear all,

I have observed recently a behaviour in ACS when an update rule seems to be executed before the create (inbound) rule when moving a node. I was able to reproduce this on different repository versions (6.1.2 or 6.2.0) in combination with various share versions, MariaDB versions, odbc connector versions and even SDK (Maven) based development environments.

The whole case can be demonstrated by having two rules (create, update) defined for a single folder whereby each rule executes a oneliner javascript outputting "create" or "update" into the console. If I perform the "Move to" operation from web ui (or do the drag&drop) then in some cases the "update" console output precedes the "create" console output. This behaviour is consistent for each system run i.e. after some restarts the order is always wrong (regardless of how many times I move the file) and after some restarts the order is always as one would expect i.e. the "create" is outputted first.

We use docker-compose and as written above the behaviour is even observable in SDK (Maven) generated projects (4.0.0 or 4.1.0) and it seems to be independent of the (run.bat ) purge (i.e. sometimes a purged project starts and the order is wrong). I'm not sure if I have seen such behaviour in 5.2 (and related SDK projects).

I'm not sure if this is a bug, but I would expect that the create rule is always triggered and executed before an update rule for a node that is moved from one folder to another. Did someone experience a similar behaviour?

Kind regards,

Jan

PS.

The rule configuration (on one image for sake of simplicity):

And the scripts:

insert.js

logger.error("*** insert ***");

update.js

logger.error("*** update ***");

Find more posts tagged with

Alfresco Content Services

Comments

afaust

This is most likely not a "bug", rather simply a result of the way rule triggers are implemented in Alfresco and some secondary functionality. Any rule trigger is essentially based on a policy / behaviour in Alfresco. Now when a move/create occurs, then all of the move/create-related behaviours are collected in a list of functionality to be sequentially executed. One of these behaviour now may be a piece of logic that performs some secondary update, e.g. inherit metadata from the parent, and that triggers an update event. Now, this update event still part of the move/create handling in that one move/create bevaviour, and needs to be processed before the next can be invoked. So the update event will collect all the update-related behaviours and execute those - among them, the rule trigger for update rules.

That secondary move/create-related behaviour can be anything - it can be another configured rule inherited from a higher-level folder, it can be a behaviour of some 3rd-party addon, or some very specific part of functionality in an official Alfresco addon. Any constellation with cascading update processing is prone to this seemingly incorrect order, and since log files never show the nesting of those processes (without printing an explicit stack trace), the events look to be out of order, but it's more correct to state that the events are in order, but the event processing may not be in all situations.

jan-prochaska

Thank you for sharing your thoughts, the problem I have with this behaviour is:

- it's prone to change after the system restart (during the run it's stable and the order is always correct or always "incorrect")

- it's making the use of dedicated rules (inbound only rule + update only rule) on the same folder hard to use. If this is really meant to work this way, it would be good to emphasize this in the documentation, I haven't found such note in docs, and I think it would be useful for users planning their rules so they know that they cannot rely on the fact that their executer for the inbound rule is executed first.

About the "secondary behaviour" - I didn't debug this into details yet, but I was in the top level folder of SWSDP site, where I created two folders "FROM" and "TO", the latter having the two rules defined. I'm not aware of any other rules on this site and there shouldn't be anything declared "above". I couldn't figure out if I'm doing something wrong (I have basically created two simple rules), but I was disappointed to learn about this behaviour.

Kind regards,

Jan

jan-prochaska

Dear Axel,

I have given this issue a third look, and there are two separate problems here.

1. any move triggers (is able to trigger) an update rule

2. these updates are executed always before inbound rules or always after inbound rules

While the 2. behaviour is still a mystery (and depends on restart and conditions unknown to me), there is an explanation for the 1. behaviour.

When moving a node the method markCascadeUpdate in the org.alfresco.repo.node.CascadeUpdateAspect class updates two properties (afaik for indexing purposes), namely: cascadeCRC and cascadeTx. These updates then trigger any update rule defined on the folder.

I think that this behaviour is not practical from ordinary user's point of view. When moving a node, the user is not updating it (at least not from a business process point of view, its updated internally for reasons unrelated to user's business logic). I think that such technical events should have been ignored in the OnPropertyUpdateRuleTrigger (which evaluates the changed cascadeCRC/cascadeTx as update) or there should have been at least some way to ignore them easily (e.g. ignore setting in a bean for properties, similar to for example ignoreEmptyContent setting).

Kind regards,

Jan