Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.A Rules component is saved as config entity. When adding an action to a rule that component should show up in the action plugin selection. The context of that action is the context of the Rules component.
Create a plugin deriver that exposes each Rules component as action or condition plugin.
Comments
Comment #2
klausiStarting at https://github.com/fago/rules/pull/399
no context and provided context yet.
Comment #3
fagogood start. added some comments.
Comment #4
klausicontext and provided context works.
TODO:
* integrity check, but that depends on #2658944: Integrity check on action and condition plugins, so should probably be a follow-up.
* calculating dependencies in the integrity check, but we don't have that at all yet for anything.
* access checks. Since we don't have #2418165: [META] Rules condition and action plugin access yet also not much we can do now.
Anything else that is missing and should be done?
Comment #5
fagoI think having those as todos is fine. But imo at least this should take care of saving changes properly, i.e. postpone auto-saving until the very end of the execution and do not save twice if both component and rule manipulate/autosave the same object.
Besides that it would be nice if we could get away without setting up the whole typed data objects for variables again as I could imagine this becoming a performance issue if one uses many components else.
(added a comment to the PR also)
Comment #6
fagoDo we have an issue for calculateDependencies()? I've just added RulesComponent::calculateDependencies() as API for modules that want to re-use components in #2671200: Clarify how compenent variables can be provided back.
Comment #7
klausiImplemented a test case to avoid double auto-saving.
I'm wondering if there is a case where a component executed as action has internal variables need to be auto saved that are not visible to the parent in any way? What would be an example for that?
I thought about the entity create action, but it does not do auto saving by itself. Maybe it should?
If an entity is created and then a data value is set on it then it is marked for auto saving. We need to test if that works in a component that is executed as action.
Comment #8
fagoDefinitely, the provided entity needs auto-saving. If that's not the case, it's a bug as you create an entity and it won't be created ;)
So yeah, I also think that would be a valid example: Have a component which you pass e.g. the node title, and the owner and it creates a node, or a log message (entity). No need to pass the variable back, but it must be saved.
Comment #9
fagoreviewed the PR and added some remarks -> nw.
The saving implementation in generally, but in particular the test coverage looks great already!
Besides that, this also misses coverage for conditions. But they are easier as they have no auto-saving and work analogously, so I think they can be a follow-up.
Comment #10
klausiReady for review again.
The biggest thing left is now provided_context_definitions (as in the PR) vs provided_context (as in 8.x-3.x). I think we should clearly separate the parameters to a component (= context) vs. the provided variables of a component (=provided context). I think it is very confusing to just have a list of context names that point to the context list? I think we should have a clear API that gives you 2 separate lists: the context and the provided context.
Comment #11
fagothanks! added a few more remarks which should be easy to fix - see PR.
As mentioned, the provided context change makes a lot of sense.
Comment #12
klausiThanks, ready for review again.
Comment #13
klausiFollow-up created: #2681973: Add test for nested auto saving with component action
Comment #15
klausiMerged.
And another follow-up: #2681983: Expose Rules components as condition plugin