restsbook.blogg.se - Drupal rules reset value to null

#Drupal rules reset value to null how to
#Drupal rules reset value to null update
#Drupal rules reset value to null Patch
#Drupal rules reset value to null code

I exported the rule and manually fixed the code to have the param included and with the value "", and it pass the integrity check.This page presents the latest published version of JSON:API, which isĬurrently version 1.1. I am still getting the "Error: Missing configuration for parameter" on the rule, when calling the component, leaving the parameter empty. I have a rule, which call a rule component, with one param set as "allow null".

#Drupal rules reset value to null Patch

I successfully implemented the #24 patch on D7.38 and rules 7.x-2.9.

The "Allow empty" checkbox is now after the variable usage, considering that it's only applicable if the variable is indeed a parameter.

The "Allow empty" checkbox is only enabled if the variable usage contains "parameter" (which obviously is always true for condition sets).

The 'allow null' value for a variable is only set if it's a parameter and "Allow empty" is actually ticked.

The 'optional' form element key is now 'allow_null'.

This fits in with Rules lingo as far as the separation of UI terminology from developer complexity is concerned. Given Rules practically uses "empty" to mean "null", I agree that "Allow empty" is best. That leaves the ambiguity across "Optional" and "Allow null". no "required" marker when executing) is out.

So, actually making a parameter optional (i.e. Specifically, the number and order of arguments for an action can matter if an action is programmatically executed with variable arguments for RulesAction::execute().

#Drupal rules reset value to null update

Perhaps, then, a checked "required" option should be inferred as empty($info) as well as If we are in agreement, could you update the patch to reflect this?Īfter digging through Rules internals for 5+ months, I've discovered that "optional" can potentially screw with how actions can be executed. Now that I think about it, 'required' is actually another thing isn't it? "Required" should technically mean the inverse of "optional". field values) of a node, some of which are not required "Set a data value" should abort, but the component itself shouldn't.

An example would be to set a few attributes (i.e. Rules will not abort the component for you if a non-required parameter is empty. The checkbox is there to allow configuration of components not every one of whose parameters must absolutely be non-empty for the basic preconditions of the component to be satisfied, i.e. If you look at rule() docs, it specifically points out the parameter array structure is the same as in hook_rules_action_info(), i.e. This isn't really an API change, so much as a new UI feature. Tagging with Docs tag, so discussion can re-continue past commit fix. ❻ecause 'allow null' is good DX, while 'required' is good 'UX'? Wasn't expecting that, but makes sense. > 'allow null' => !$item should be 'allow null' => empty($item) Maybe I should start a fork of Rules with Functional Tests if I'm really willing to see this through.Įither way, I think this is rtbc, and we can decide, latest, upon commit, if it 'Needs tests', at least based on insights from my recreational Core Watching. It also gives the 80%(?) of users who might look at the code more to 'get' when they read it, which could help them to become developers after having more meaningful insight and staying motivated to dive in further. While I understand that the test cases in Rules Test, which are like rules test case 1 expects 'variable one' to show message 'test 123', are primarily there for testing, though IMHO, it'd be a direct way to solve two hungry birds with one rice grain (ha). I also advance this, because in my case, I don't understand it yet, and I know 2-3 examples would knock it out of the park. Mine is just general, that if you do decide to make one, please look at it also from the docs side of things. On "needed tests", I would prefer to look to your recommendations. Could you please link? UI widget tests are not something I'm not familiar with at all. Grepping didn't reveal an allow null test. > do you think this needs tests, or is this covered by the allow null test (notwithstanding the UI widget)? Also, would the introduced "allow null" default behavior affect any existing configurations?

#Drupal rules reset value to null how to

I think the unticked default is a good choice, because then users wouldn't have to learn how to use "Required" values until they needed that feature. I'm fond of examples with a system message that makes some sense, e.g. So, the question is, how would "Required" values be used? Cool twist.

The example in OP is no longer valid, because "allow null" will be afforded by default, if unticked is default. This seems like it'll be very useful, but I don't yet have a handle yet on when it makes sense to 'require' parameters or provided variables.