When a Rules component is provided in code, it does not make sense to override the variables it accepts or provides. If they are changed a module cannot rely on the Rules component anymore, because a variable may not be available anymore (a contract violation). Attached patch disables the variable forms in the UI for components in code.

CommentFileSizeAuthor
#3 1060978-rules-vars-disabled2.patch3.4 KBklausi
rules-ui-fixed-variables.patch6.32 KBklausi

Comments

fago’s picture

fago
Primary language German
Location Vienna
commented
Component: User Interface » User interface 
-    if (!empty($this->element->module) && !empty($this->element->name) && strpos($this->element->name, $this->element->module . '_') === 0) {
-      // Remove the module prefix from the machine name.
+    if (!empty($this->element->module) && !empty($this->element->name) && $this->element->module == 'rules') {
+      // Remove the Rules module prefix from the machine name.

Hm, this would be odd if the rule name isn't properly prefix.

Suggested fix:
Let's add a check to RulesPlugin::save() that throws an exception if an invalid module/name combination is saved.

>+ '#disabled' => !$this->element->hasStatus(ENTITY_CUSTOM),
Couldn't we just use that for the usual var-config-form too?

fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Needs review » Needs work
klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented
Status: Needs work » Needs review
StatusFileSize
new 1060978-rules-vars-disabled2.patch3.4 KB

Simplified patch which disables the whole form for entities in code. Yay for consistency, as the form always looks the same, entity status independent.

I added another check for the machine name handling and did not touch RulesPlugin::save() for now.

fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Needs review » Fixed

thanks, committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.