UserPreference model on "checkbox"

When forms with checkboxes is submited, data contains only “checked” inputs, not “unchecked”. This behaviour causes that UserPreference is impossieble to set to “false”.

Workaround (for now) is to create hidden field with toggling value true/false and checkbox use only to programatically change value on hidden field.

“Switch” and “checkbox” have same problem. Any of this value is not able to change when is set to true.

I believe this is normal behavior. When a checkbox is not checked, the value is not sent at all.

Knowing that, you can just check the existence of a value for that checkbox. If exist : true, else : false

1 Like

nope… this is not a solution, because you need to prepare full logic to each Preference field of that type, and check for change… and, of course, when you have separated forms for this kind of prefrences, like on screenshot, you probably “disable” or will change something what you wont change at all.

maybe i’m not good on explaining things, but… how you exactly wish solving this kind of behaviour? there are 2 main issues…

1st problem

When unchecked item is not sent you are not aware to change that value, from true to false. right? then you are not able to switch something, only if it is as radio buttons with direct values of true/false…

2nd problem

if you wish to use this kind of settings/prefrencies, you need to know exact list of prefrencies to be checked for in preprocessing (beforeSave) event, or something. right? only then you are able to correctly set “false” values on booleans

3rd problem

as i mentoined before, when you splited multiple inputs for UserPrefrence, then you need to be aware of each one for each form to update only correct properties. for now, there are no funcionality to list all user preferencies which was created/stored, you need to call each one by one, then when you wish to create some funcionality on beforeSave, then you probably need sent a list of properties to be checked or something…

“solution” (minimum effort)

if you wish to use UserPreference as a boolean with checkboxes / switches, you need to create a specific funcionality like i wrote before.

<input type="checkbox" onchange="correctValue(this,'#stop')" id="check1">
<label for="check1">Stop all questions...</label>
<input type="hidden" name="Preference[stop_annoying_questions]" id="stop">

and… of course… some javascript to fill value to “#stop” - hidden input…

function correctValue(el, target) {
   document.querySelector(target).value = el.checked ? true : false;

example pen > (hidden field is rendered as text to see if correct value is set properly.

solution with effor as faaaaak

  1. create hidden field with comma separated list of properties to be used on loop in beforeSave method.
  2. create beforeSave method on model to check if there are some input field (for now call it _prefrencies) …
  3. loop all provided _preferencies to check if is posted, if exists, and then correctly update value to false when is bool value, etc.

tell me, who will go this way?

I feel the easiest way is how PubliAlex described it.

If you got the input in $_POST, means it set to true, if not, false. You can do a one liner, no javascript required.

probably i need to say that again and again… when ist not “sent” that means, OC will not update value by default… thats that MAIN PROBLEM what i raised here… not knowledge about “if is not sent, set it to false”… this problem is not that stupid, but komplex on hidden funcionality.

when OC didn know about that field, then OC not perform change by default. then desired funcionality of UserPreference on booleans may look like broken, and are not usable as well.

When you need to perform any kind of “workaround” to achieve desired outcome, then function is not correct or is buggy…

do you understand now?

On default backend funcionality, when you create a form with switch, OC correctly update value to false. but, this funcionality not working on UserPreference model. And this is what i reported with “workarounds” when someone will use it like me (for now) without correct solution provided by devs.

@snipi you can remain calm; you will still be heard.

Now, your issue is (your first message above) :

When forms with checkboxes is submited, data contains only “checked” inputs, not “unchecked”. This behaviour causes that UserPreference is impossieble to set to “false”.

A checkbox is an on/off switch. When the switch is on, the value of the checkbox is “active”. When the switch is off, the value is inactive. The checkbox value is only submitted with the form when the switch is on.

From the World Wide Web Consortium (W3C); Forms in HTML documents

So it’s not buggy or workaround - it is what it is.

nice try… again… backend “switch” and “checkbox” works perfectly fine, right? that means, OC somewhere (from fields.yaml) knows about each field and processed each one field in background, then, when value for some “switch” or “checkbox” is not present, it for OC means, set that shit to false, right?

UserPrefrence model is not as smart as backend form… Missing knowledge about field, that is not sent, in background may set value to false. Correct or no? Like backend fields, right?

And this is problem… There are zero knowledge, zero checks, then boolean is able to be set only to true and never to false, without any of provided “solutions”.


And this is where you implement something that fits your needs, such as verifying the presence of the input in the form to set it to either true or false.

I never investigated how october team did it for the backend, but it’s probably a custom logic cause, as @apinard said, the fact to not post unchecked values is a HTML standard.

If that behavior, for whatever reason, don’t fit your need. To me, it’s a perfect viable solution to put an hidden field that stock the value you want corresponding to checked or unchecked checkbox. It can be done with a single line of javascript, that you can put in the onchange event of your checkbox.

What is the problem with that solution ?

tell me please, who exactly will keep that in mind, when backend funcionality works correct and fe implementation wont? but, for now. whatever…