Use workflow expressions in validation maps

[Luke1982]

We should be able to compare a field with another field from a related module, without using condition expression maps, but simply by (for example)

      <field>
          <fieldname>ship_street</fieldname>
          <validations>
              <validation>
                <rule>equals</rule>
                <restrictions>
                    <restiction>$(account_id : (Accounts) ship_street)</restiction>
                </restrictions>
              </validation>
          </validations>
      </field>

in this example you compare the ship street (of for example a SalesOrder) to the ship street of the related account, and demand them to be equal.

[joebordes]

This can currently be done with an expression validation. Set your expression map to

<map><expression>if $(account_id : (Accounts) ship_street) != $otherstreet then 0 else 1 end</expression></map>

(or something like that)

This is probably why we didn't add support for the related module syntax; expression can do that and more.

That said, if you want to add support for this it would be limited to only some operations due to the way that valitron works. For example, if you want to make a "required" on the related module, it would be very hard because you have to give valitron the values at the start when you instantiate the object, and then it looks for the name of the field in the array of values. I mean, we would have to preprocess the map to find related field syntax, get the values and then invent some syntax (relatedmodule_relatedfield) to add them to the array of values to validate. Seems overkill, in general.

But there is a subset of cases that could be rather easy, the ones where we compare the value in the array with the some given value (exactly the case you want above), these lines of code:

https://github.com/tsolucio/corebos/blob/master/modules/cbMap/processmap/Validations.php#L223:L234

on line 228 we use the value as given, that is where we would have to see if we have the related module syntax and use the expression evaluator to get the value and set it in $rulevalue instead of the value written in the map.

If you still think this is an interesting thing to implement (I'm not that convinced, I prefer the expression map) then please add the Hacktoberfest label to it, see if someone is up to it (it isn't that hard now that we have the pointers and knowing that evaluating an expression in coreBOS is 4/5 lines of code). If you think it isn't worth it, please close the issue after verifying that expressions cover your needs.

Thanks.