I like to recommend to also implement a checksum of the form values. If the checksum didn't change since the last safe event, we don't need to submit the request to the backend.
For performance reasons the safe event should be triggered with the onchange event, plus on an interval when the user is active in the current window (e.g. typing in a long textarea doesn't trigger the onchange event unless the focus leaves the field, so we need to do it in a timely manner while he's typing). When the safe event is triggered, it must compare the checksum of the current form with the last submitted checksum. If the checksum didn't change, the safe request can be skipped. This would have the benefit to work with an active and inactive window, enhancing the proposed behaviour with an additional reduction of network load, avoiding to submit unchanged content.
Once implemented, this makes the experimental feature "Run only on form change" obsolete.
heroicnick → credited rvolk → .
heroicnick → credited rvolk → .
heroicnick → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
sanduhrs → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
dan2k3k4 → credited rvolk → .
Creating users and roles always opens up a couple of related issues. To do it right, the status page should indicate if something is missing, this way site builders can still extend the user and role model, while the module will only ensure the minimum requirements are met. After uninstall a message to the user might be sufficient, informing him that he can delete the user now. So the optional configuration approach in combination with a status checks should be sufficient for the current case. If we want to remove the user and role, we must make sure that it has not been modified or repurposed.
Once the status check is in place, we can use the same routine in the install process and only create the user if missing.
The preview site feels like a no brainer, should be fine to simply remove it.
Refined description.
We also discussed this at the Drupal Dev Days in Vienna 2023, the manually sorted list in the management view is responsible for the order of execution, so this kind of makes sense. However, the order should be only relevant per event type, where it's going to be validated and sorted.
Also see https://ecaguide.org/eca/usage/#admin-ui
With the recent development of event specific execution, it would be helpful to see the execution of rules per event type and not all at once. A filter would be certainly helpful, but maybe we should consider a dedicated view of execution order and not mix it up with the management view, where we could handle a multitude of rules.
To get started with I would appreciate:
- a text-filter for "Model" names
- a multi-select-filter for available "Events"
- a bool-filter for "enabled"
Furthermore, with a fresh and empty installation no list is shown, but we can see the save button. It's not really a bug, but just not necessary when there are no rules to be drag & dropped.
A pager might become handy, when we have more than 50 rules. But a pager would break the sorting feature, which would be another argument to specify the execution order per event and not in the management view. In this case a simple counter behind the listed event could indicate how many rules are using the same event, e.g.:
- Update content entity (Content: - any- )
- Presave content entity (Content: - any- ) [Used by 2 rules]
Clicking on the "[Used by 2 rules]", could bring up a screen where we order the rules accordingly.
Keep up the great work, it's already very useful!
dan2k3k4 → credited rvolk → .
spitzialist → credited rvolk → .