Download & Extend
Rules » Issues

Argument should called processor even if the unwrapped value is null

Posted by hanoii on February 2, 2012 at 11:07pm
Project:Rules
Version:7.x-2.x-dev
Component:Rules Engine
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (won't fix)

Issue Summary

Not sure if this is a bug, but spent a few hours stuck because of this and I wonder if this is like this for any reason and whether this might be better in another way.

I have an action that changes one value of a node before saving it. (action: set a data value) I am using the PHP evaulator for the data selector so that I can do some handy PHP stuff in there that I need.

I want to use the value stored in the node field but it was starting off with a null value (this is fine for me). Because of this, the PHP processor was never triggered and so I always got a null value in the field.

I tracked the issue down to getArguments() in which the process of the processor is only triggered if the selector has a value other than null.

I was hoping to run the processor even with the null value.

Attached is an easy fix for this, but not 100% sure of the implications or if this was made like this for a reason. If not this, then some better documentation in the processors has to be made easily available.

Login or register to post comments

Comments

#1

Posted by hanoii on February 2, 2012 at 11:08pm
Status:active» needs review

#2

Posted by hanoii on February 2, 2012 at 11:09pm
AttachmentSizeStatusTest resultOperations
argument_process_with_null_values-1426618-1.patch911 bytesIdleFAILED: [[SimpleTest]]: [MySQL] Unable to apply patch argument_process_with_null_values-1426618-1.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.View details | Re-test

#3

Posted by System Message on February 2, 2012 at 11:10pm
Status:needs review» needs work

The last submitted patch, argument_process_with_null_values-1426618-1.patch, failed testing.

#4

Posted by hanoii on February 3, 2012 at 12:28pm
Status:needs work» needs review

re-rolled with proper paths

AttachmentSizeStatusTest resultOperations
argument_process_with_null_values-1426618-4.patch839 bytesIdleFAILED: [[SimpleTest]]: [MySQL] Unable to apply patch argument_process_with_null_values-1426618-4.patch. Unable to apply patch. See the log in the details link for more information.View details | Re-test

#5

Posted by System Message on February 3, 2012 at 12:29pm
Status:needs review» needs work

The last submitted patch, argument_process_with_null_values-1426618-4.patch, failed testing.

#6

Posted by hanoii on February 3, 2012 at 12:38pm

A proper one I hope!

#7

Posted by hanoii on February 3, 2012 at 12:38pm
Status:needs work» needs review

A proper one I hope!

AttachmentSizeStatusTest resultOperations
argument_process_with_null_values-1426618-6.patch815 bytesIdlePASSED: [[SimpleTest]]: [MySQL] 249 pass(es).View details | Re-test

#8

Posted by System Message on February 3, 2012 at 12:44pm
Status:needs review» needs work

The last submitted patch, argument_process_with_null_values-1426618-6.patch, failed testing.

#9

Posted by hanoii on February 3, 2012 at 2:36pm
Status:needs work» needs review

#7: argument_process_with_null_values-1426618-6.patch queued for re-testing.

#10

Posted by hanoii on February 3, 2012 at 2:37pm

I run the tests of 7.x-2.x locally and they all pass.

#11

Posted by hanoii on February 3, 2012 at 3:11pm

ok, now we are good with tests, any comments?

#12

Posted by klausi on February 7, 2012 at 11:36am

Looks good, not sure why we had to do that isset() check in the first place. The "0" index of the returned array must always be set, so this should not trigger any PHP warnings.

#13

Posted by fago on February 14, 2012 at 5:22pm
Status:needs review» closed (won't fix)

hm, I'm not sure about that. Data processors are designed to process the data value. But if there is no value to process, why should they be invoked?

E.g. we also have the date offset processor. Putting an offset on a NULL value would certainly lead to unexpected results. Also changing this behavior would affect existing processors and so mean an API change right now.

I'd suggest to move the PHP code to a separate PHP action, or even better into a module.