ApiStructureTest has a lot of logic for validating Action API settings
arrays during CI. Some of that logic should be part of ParamValidator
instead.
Bug: T242887
Change-Id: I3c3d23e38456de19179ae3e5855397316b6e4c40
Depends-On: I04de72d731b94468d8a12b35df67f359382b3742
Rename PARAM_IGNORE_INVALID_VALUES to PARAM_IGNORE_UNRECOGNIZED_VALUES,
and make it only ignore the "badvalue" errors thrown by EnumDef for
unrecognized values instead of ignoring every kind of error.
This better matches historical Action API behavior.
Change-Id: Ifdb9063c0a2e82c728e98065e2ac950f4a713552
This fixes a few things in ParamValidator's use of messages:
* Values need to be stringified in various places.
* Don't pass the value to paramvalidator-toomanyvalues, to make it match
apierror-toomanyvalues. We weren't using it anyway.
* Rename "paramvalidator-help-multi-sep" to match
"api-help-param-multi-separate".
* Fix attempts to use messages "paramvalidator-param-default" and
"paramvalidator-param-default-empty" that don't exist.
* EnumDef's logic for selecting between enummulti vs enumnotmulti
was backwards.
* Sort enum values in getParamInfo() output.
* Adjust some message texts to match equivalent former Action API
messages.
Change-Id: I1551a59bd110f12e478de7292a00f9a767cd94ca
When the values being validated come from PARAM_DEFAULT, EnumDef
shouldn't warn about them being deprecated.
Making this happen requires a new option passed through from
ParamValidator::getValue() to ::validateValue() to TypeDef::validate().
Change-Id: I8535f8757485748bccb7a756b71ce61fdf28faa1
Trying to get away with returning a single code and parameter-list that
was supposed to represent both human-readable and machine-readable data
was a mistake.
This patch converts it to use DataMessageValue, which represents the two
separately and also provides guidance for supplying translations of all
the error codes.
This also eliminates the "describeSettings()" method that was trying to
serve multiple use cases (in terms of the Action API, action=paraminfo
and action=help). It's replaced by two methods that each serve one of
the use cases. Also some of the functionality was moved out of the
TypeDef base class into ParamValidator, to better match where the
constants themselves live.
Also I wound up creating a NumericDef base class so FloatDef can share
the same range-checking logic that IntegerDef has. I probably should
have done that as a separate patch, but untangling it now would be too
much work.
Bug: T235801
Change-Id: Iea6d4a1d05bb4b92d60415b0f03ff9d3dc99a80b
With the introduction of a REST API into MediaWiki core, we're going to
want to share parameter validation logic rather than having similar code
in both the Action API and the REST API. This abstracts out parameter
validation logic as a library.
There will be at least two follow-up patches:
* One to add calls in the REST API, plus the interface for the REST API
to do body validation. Should be reasonably straightforward.
* One to adjust the Action API to use this. That'll be much less
straightforward, as the Action API needs some MediaWiki-specific types
(which the REST API might use too in the future) and needs to override
the defaults on some of the library's checks (to maintain back-compat).
Bug: T142080
Bug: T223239
Change-Id: I5c0cc3a8d686ace97596df5832c450a6a50f902c
Depends-On: Iea05dc439688871c574c639e617765ae88a75ff7
