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
These are a mess and hard to de-localize. Also, the schema is
already documented as not including the namespace in this field.
A proper migration would be very difficult, so we'll have to remember
that our data includes this glitch and manually strip namespace
prefixes before the deployment date, as needed.
Change-Id: If2a4dd865b95458dc63162460f252500fd52436e
Adding a new widget that inherits from MultilineTextInputWidget but
is initialized with only one row and prevents using the return key
to add new lines.
Bug: T263533
Change-Id: I5423f5f04075d21abd7acf09b622fd6444feeeb2
… 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 is needed for metrics collection.
The patch shifts responsibility for filling out an empty record when
there is no existing TemplateData, or it's corrupt.
We could clean up further by making logic robust to missing `params`
in the original templatedata, so that an empty structure is simply
`{}`.
Bug: T260343
Change-Id: I6ddc2660257890290cd40c54f9c8507ab5206d6c
This is an important warning, and should not just be hidden.
Instead show it in the dialog as well in case the user ignored
it on the edit page.
Change-Id: If6f2d4b15157096a915186921d767a860edbc86a
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
This does not have any effect on how this code behaves. It's
only relevant when a human reads the code. I tried to bring the
properties in an order that makes the most sense, grouping stuff
that clearly belongs together, as well as following how stuff is
ordered on
https://www.mediawiki.org/wiki/Extension:TemplateData
Change-Id: Ibbe1027023f8d87bbd0a70411882a25671918670
Seperate different maps of maps-object into different panels that
contains text-area to edit the map, delete button to delete the map, and
can be navigated through using a side-bar, that also have "Add new map"
button at the top to add a new map.
Bug: T258820
Change-Id: Ib53a73203f6010b3fd8a5cd78c74c904be2340f2
