Page MenuHomePhabricator

[Bug] wblexemeeditformelements API requires to resubmit unrelated values
Closed, ResolvedPublic

Description

The "wblexemeeditformelements" API newly implemented in T184409 specifies a "data" parameter that must look like this:

{
  "representations": { "en": "…" },
  "grammaticalFeatures": []
}

The two fields are currently required. Users of this API must always submit both fields, even if the user only wants to touch one of the fields. Not only that. That other field must contain all the old, unchanged values in order to not make an accidental edit to the field. This makes this API hard to use, and yields the danger of unintentional removals when users run into this issue and aren't aware of all implications.

This is highly relevant because this API currently is the only one that allows to edit these fields. Later, "wbeditentity" might also support editing these fields. However, this will not make the issue raised in this ticket obsolete. It will just raise the same questions again.

It's also not possible to add or remove individual values from either of the fields without resubmitting all the other values that should not be edited. But this is an other question, unrelated to what this ticket is about.

Event Timeline

daniel subscribed.

The concerns raised are appropriate for a public API, but this isn't a public API. Discussion should continue on the ticket for making the public API for editing Lexemes.

It seems there is no clear enough ticket regarding public API that could be referred to. The only subtask of T168263 I see mentions the public API is T166691. Let's think if we should create some new ticket(s).

There is no such thing as a non-public API. All APIs are public. The only thing we can do is mark one as unstable (and we did), but this does not make it private. So to close this ticket I would like to know how we are going to make it obvious to users they should not use this API, and how we are possibly going to enforce this?

WMDE-leszek claimed this task.

Per wbeditentity handling "atomic" edits to forms, and changes to parsing using input to the API mentioned here, this should be solved now.