api4 explorer: make boolean params work in cv (short syntax)

[highfalutin]

Overview

Fixes https://lab.civicrm.org/dev/core/-/issues/4129

Before

In API v4 explorer, boolean params are rendered in CV (short) syntax as true or false. The generated code does not work in cv.

After

Params are rendered as 1 or 0. Generated code works in cv.

[civibot]

(Standard links)

• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[highfalutin]

Well actually in some cases the cv command still doesn't work... cv interprets all param values given in key=value syntax as strings. Even if we pass, for example, useTrash=0 instead of useTrash=false, the param value will still be string "0" and so type-checking will fail and throw an error.

In at least one case (\Civi\Api4\Generic\AbstractAction::setCheckPermissions()), the string is explicitly recast to a boolean, and this works correctly for checkPermissions=0. But for checkPermissions=false, the string "false" is recast to boolean true, and no error is thrown (except maybe "Authorization Failed").

[totten]

@highfalutin I think your original intuition is pretty good -- passing 0/1 on CLI generally works better than passing "false"/"true". This is historically true in similar interfaces (like cv api3 and drush cvapi); it's true in related ecosystems (like C and MySQL); and it checks out for several things in cv api4:

• checkPermission=0: Numeric-bool works. String-bool doesn't.
• +v do_not_sms=1: Numeric-bool works correctly. String-bool doesn't.
• +w do_not_phone=0: Numeric-bool works correctly. String-bool doesn't.

That is curious that useTrash differs. I think the difference between useTrash and checkPermissions is this:

• $checkPermissions has a real setter method with a PHP type declaration.
  • When one calls setCheckPermissions(1), it applies PHP type-casting rules (ie 1 ==> true).
  • It stores $this->checkPermissions=true.
  • Later on, Api4's ValidateFieldsSubscriber accepts this.
• $useTrash has a magic setter method with no PHP type declaration.
  • When you call setUseTrash(1), it will pass through any mixed value without validation or casting.
  • It stores $this->useTrash as 1.
  • Later on, Api4's ValidateFieldsSubscriber rejects this.

(To confirm this is the difference: you can add a real setter method for useTrash, and it cv api4 Foo.delete useTrash=0 will work.)

---

IMHO, this patch is better than what it was doing before. 👍

Aside: There is a related issue in how the explorer renders booleans in the "Where" (+w) and "Value" (+v) clauses. But that doesn't have to stop this.

[eileenmcnaughton]

I added merge-ready based on @totten's "IMHO, this patch is better than what it was doing before. "

I think some related issues came up - but they don't need to be in scope for this PR so I'll just let @highfalutin have a chance to read & respond

[highfalutin]

@totten thanks for the comments, and thanks for #25595 which goes a long way to addressing the issues I mentioned in #25589 (comment) above.

In addition to the +where problem you mentioned, I think it's also not ideal for strings to get turned into booleans silently in some cases (I'm looking at you, setCheckPermissions()), but none of that should prevent this PR from getting merged.