feature: multiple choice checkbox in editor

[johnnyblasta]

Closes #1518
Adds a multiple choice checkbox to the editor with a possibility to have a free text choice.

Configurable like this:

{
        "name": "atgardsforslag",
        "title": "Åtgärdsförslag: ",
        "type": "checkbox",
	"options": [
		"Kronhöjning minst >4.6m",
		"Kronhöjning minst >3.2m",
		"Utrymme beskärning ",
		"Borttagnings av döda grenar",
		"Återhamling",
		"Hammling",
		"Leverans högstubbe",
		"Kronretireringbeskärning",
		"Formträdbeskärning",
		"Uppbyggnadsbeskärning",
		"Säkerhetsbeskärning",
		"Avlastbeskärning",
		"Borttagnings av vatten skott",
		"TRAQ 2",
		"TRAQ 3; Klätterandebesiktning",
		"TRAQ 3; Resistograph/tomograph",
		"TRAQ 3; Advencerad Rotbesikning",
		"Annat:textbox"
	]  
}

[steff-o]

Even most of the stuff works as expected I'm not convinced.

I don't think that it should be called checkbox. It feels more like a new input type like "checkedlistbox" or "checkboxlist" or "checkboxgroup", with possibility to add extra values. Or a more user friendly dropdown/listbox with multi select. A checkbox with a list of options feels kind of awkward to me.

But my main concern is about the additional options that the user can add.

1. The configuring syntax: it is a bit magic and limits the possible options values. Not that it is likely that someone will have an option that actually contains ":textbox", but still.
2. While the configuration theoretically supports several "other" options, the implementation only fully supports one. It is possible to add several "other" values, but when re-read only the last is used for all "other" checkboxes.
3. The configured "other" title ("Annat" in your example) does not enable localization the same way as other controls as it is hardcoded in the configuration.
4. It is easy to trick the mechanism by using semicolon i an "other" value. If a semicolon is present in the options list it also breaks, but that can be avoided in configuration time, but in "other" fields it should be escaped.

My suggestion is to omit the possibility to configure the use of "others" in the options list and instead have a flag in a "config" object that says if it is allowed to add "other" values, and possibly one or many. If many "others" are allowed a new "other" row is created when the one visible is checked. On re-read, all options from database that are not in the options list are added as pre filled "others", or like the regular options.

It should also be possible to configure the separator, now hardcoded to semicolon.

Other than that, there is a bug when using this feature in related tables as the input fields are not getting unique ids. It is however a result of a bug in the existing code for checkbox that does not include layer name in the id.

[johnnyblasta]

I think I prefer checkboxgroup if it should be a new input type.
I can take a look at reworking it, so it's less hokus pokus in the implementation.

[johnnyblasta]

• Introduced a new input type checkboxgroup
• Changed the configuring syntax, so that it's not magical.
• Removed the hardcode for separator.
• Added option for the freetext field so it's not harcoded and makes it possible to add more than one.
• Added the possibility to have the text and value of the choice to be different.

Example configuration:

{"name": "atgardsforslag",
 "title": "Åtgärdsförslag: ",
 "type": "checkboxgroup",
 "separator": ";",
 "freetextOptionPrefix": "freetext_option:",
 "freetextOptionValueSeparator": "=",
 "options": [
    { "text": "Kronhöjning minst >4.6m", "value": "Kronhöjning minst >4.6m" },
    { "text": "Kronhöjning minst >3.2m", "value": "Kronhöjning minst >3.2m" },
    { "text": "Utrymme beskärning ", "value": "Utrymme beskärning" },
    { "text": "Borttagnings av döda grenar", "value": "Borttagnings av döda grenar" },
    { "text": "Återhamling", "value": "Återhamling" },
    { "text": "Hammling" },
    { "text": "Leverans högstubbe", "value": "Leverans högstubbe" },
    { "text": "Kronretireringbeskärning", "value": "Kronretireringbeskärning" },
    { "text": "Formträdbeskärning", "value": "Formträdbeskärning" },
    { "text": "Uppbyggnadsbeskärning", "value": "Uppbyggnadsbeskärning" },
    { "text": "Säkerhetsbeskärning", "value": "Säkerhetsbeskärning" },
    { "text": "Avlastbeskärning", "value": "Avlastbeskärning", "type": "textbox" },
    { "text": "Borttagnings av vatten skott", "value": "Borttagnings av vatten skott" },
    { "text": "TRAQ 2", "value": "TRAQ 2" },
    { "text": "TRAQ 3; Klätterandebesiktning", "value": "TRAQ 3; Klätterandebesiktning" },
    { "text": "TRAQ 3; Resistograph/tomograph", "value": "TRAQ 3; Resistograph/tomograph" },
    { "text": "TRAQ 3; Advencerad Rotbesikning", "value": "TRAQ 3; Advencerad Rotbesikning" },
    { "text": "Annat", "type": "textbox" }
  ]  
}

[steff-o]

No doubt that this will be a great addition and the text and value approach is a great feature, however it seems like we don't share the same vision when it comes to the "other" values. You may have a stronger case, but here is my take on it:

• It could possibly simplify backend operations if all values including the others are stored in the same way in the database. Your approach is robust when it comes to roundtripping in Origo, but if you want a backend integration it will be necessary to parse the string in the database. If all values where stored using only a separator, any list splitting operation will do. I think it would be possible to implement it in that way if you don't require to match the value against a specific "other" label as described in my previous comment.
• The text property on the "others" is a candidate for localization as a part of the GUI, not a part of the values, which makes me think it should be a localized string in editform. Also if made that way, it won't be necessary to store it in the database which makes previous point easier.

Do what you want with that, but I request a change on the id-creation.

[steff-o]

... and tabbing does not highlight the checkboxes ...

I've made the changes steff-o asked for

[johnnyblasta]

I think I fixed the unique id @steff-o requested, so take a look.
Added highlight for all inputs i form, since all seemed to be missing and also some labelling was missing or incomplete.

As for the the other value I think I will leave it as it is for now since it works and is flexible for possible use cases. I see there is possible ways to do this, for one would to save the values as a json object. Yes it could be localized if it only is a others field, but perhaps some will use it more creatively.

[steff-o]

LGTM.

Yes, serializing to JSON can be an option in the future when someone discovers the need for it. The current implementation seems to fulfil the current requirements.