Page MenuHomePhabricator

Save Wikidata edit when submitting client edit modal
Closed, ResolvedPublic13 Story Points

Description

As a Wikidata Bridge tester I want to save a first dummy edit.

BDD
GIVEN a Wikidata Bridge modal
WHEN I change the value in the text field
AND click save
THEN the corresponding value on the repository is changed and the overlay is closed

GIVEN a logged-in editor on the client
WHEN making an edit through the Wikidata Bridge
THEN the edit is attributed to the same username on the repository (not an IP)

Acceptance criteria:

  • the edit made in the client is saved on the repository
  • the edit is made under the same username on the repository as the one logged-in on the client
  • save button as described in figma
  • save button is labeled “save” (hard-coded) – correct handling of wgEditSubmitButtonLabelPublish setting and translation will be separate (tbd)
  • if an error comes up it will be shown on the modal
  • on success, the overlay is closed

Notes:

  • No need to worry about edit flows yet. Just replace the value unconditionally.
  • No need to worry about custom edit summaries. The default ones are fine.
  • Adding an edit tag to the edit is part of the next story
  • Special handling of blocked users or protected pages (on either wiki) is not within scope of this task.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 1 2019, 2:25 PM
Charlie_WMDE renamed this task from Save Wikidata edit when submitting client edit popup to Save Wikidata edit when submitting client edit modal.Jul 4 2019, 4:00 PM
Charlie_WMDE updated the task description. (Show Details)
Lydia_Pintscher updated the task description. (Show Details)
Lucas_Werkmeister_WMDE set the point value for this task to 13.

The simplest API we can use for this is wbsetclaimvalue: action=wbsetclaimvalue&claim=ID&value="VALUE"&snaktype=value&token=TOKEN. However, this won’t work when we want to edit qualifiers or references later, or want to support edit flows that edit one or more statements. For that, we’ll need to use wbeditentity. And I think we should consider using that module right away – we don’t need to send it the full entity data, this is a working example for the data parameter:

{"claims":{"P236":[{"type":"statement","id":"Q50$fc414696-44fa-0942-e531-95f315e7c0bb","mainsnak":{"snaktype":"value","property":"P236","datavalue":{"type":"string","value":"7722dd"}}}]}}

We only need the property ID, statement ID, and value (assuming that “main snak”, “custom value”, and “string” are hard-coded limitations for the time being) – barely more than for wbsetclaimvalue. Currently, wbeditentity results in less useful edit summaries, but that’s already being improved independent of this task (see T220696).

One drawback of wbeditentity is that it responds with the full new entity data, which is wasted bandwidth for us (we’re about to reload the page anyways). Perhaps we should add a parameter to control/reduce the response – I assume there are other users that don’t need the full response either.

During task break-down we decided to no implement the context-aware (disabled if nothing is changes yet) save button yet => T230342. /cc @Charlie_WMDE

note: we need an extra ticket for the close button and its behavior

Michael moved this task from To do to Doing on the Wikidata-Bridge-Sprint-3 board.
Ainali added a subscriber: Ainali.Sep 16 2019, 9:21 PM
Lydia_Pintscher closed this task as Resolved.Sep 20 2019, 10:32 AM
Lydia_Pintscher claimed this task.
Lydia_Pintscher moved this task from Verification to Done on the Wikidata-Bridge-Sprint-5 board.
Lydia_Pintscher added a subscriber: Lydia_Pintscher.

\o/