fix(controller): Fix false booleans in multipart/form-data

[nickvergessen]

Summary

I was debugging an issue reported by our frontenders with a new API (ref nextcloud/spreed#13871 (comment))
Turns out sending the boolean false in a post request sees it as "false" and therefore evaluates to true.
We have some code in place to "sometimes" translate that to false (see diff). I now need to extend this to multipart/form-data.

But at the same time I wonder why the check is there at all? When the controller requests a boolean, shouldn't we always convert "false" to false independent from request type?

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[provokateurin]

What about query parameters? There we currently only allow 0/1 for booleans and openapi-extractor has a quirk to workaround this, but it would be great if we could send proper boolean true/false

[nickvergessen]

What about query parameters? There we currently only allow 0/1 for booleans and openapi-extractor has a quirk to workaround this, but it would be great if we could send proper boolean true/false

That is already working properly with the settype path:
https://3v4l.org/SolRs

<?php

$value = '0';
settype($value, 'bool');
var_dump($value);
// bool(false)

$value = 'false';
settype($value, 'bool');
var_dump($value);
// bool(true)

In alignment via chat, I will make it match in all cases when the value is 'false' and the controller wants a boolean

[provokateurin]

That is already working properly with the settype path:

Hm ok then I have to check again 🤔