* deprecated means "please do not use this".
* required means "you must use this".
* suggested means "it's a good idea to use this".
* optional means "you typically don't need this".
There is no combination that makes any sense. They are really
exclusive to each other.
Still we have to keep the three checkboxes for backwards
compatibility reasons. It was always possible (and will probably
continue to be possible) to have more than one of the three fields
enabled. While users like VisualEditor will make a good guess (e.g.
ignore the rest when "deprecated" is checked) I really think we
should not attempt to hide (and auto-fix) it in this dialog. That's
why the proposed code continues to show the old checkboxes when
more than one is checked.
Bug: T202851
Change-Id: I994268d658602761b180f489bedb50b91fe0c419
Two main mistakes:
* The {...foo} syntax is for a variable number of parameters.
But this is not the case here.
* Optional parameters should be marked as such via [foo].
Change-Id: I0c26ea44fab6094616443ce8fae4fd47c61fd7c4
Parameters may include a `suggestedvalues` property, which is rendered
in the UI for some parameter types.
TemplateData editor UI elements are implemented behind the
TemplateDataSuggestedValuesEditor feature flag.
Bug: T271897
Change-Id: I14012c79b3fa0d48c58fd8999584cc03ec03575e
… instead of 0. Conditionally add a dash in front as well to
avoid confusing results like '1' + sequence number = '12'.
Change-Id: I345704b00ba3812c4905f85e35cf21a6dfd05437
I looks like the Model.params data structure is build in a way
that it allows mismatching parameter "keys" and "names". E.g.
{
"a": { "name": "a" },
"a0": { "name": "a" },
}
There are comments in the code that suggest this is
intentional.
I found code that confused these two values and tries to use
the name as a key, for example. This fails, messes up the
paramOrder, and such.
This should not have much, if any effect for users because
users are blocked from doing this anyway, e.g. buttons get
disabled.
Change-Id: I2067024ad8d5b8e985a4f162cf6875f523777a6c
This fixes a series of issues:
* The JS implementation had a trim() in one place that was
missing in PHP.
* The actual parameter name in the paramNames/$params array was
trimmed, but the "normalized" name (this is only for duplicate
detection) was not trimmed.
* It was possible for an empty parameter to show up.
This resulted in very strange behavior, e.g. {{{ 1}}}{{{1 }}}
was detected as "1" and "10" (?), i.e. it would try to renumber
the duplicate in a strange way (string "1" plus a counter that
starts with 0).
Change-Id: I0a6371f3633b03b5b21809ecd06ea4c72d7d914d
