Page MenuHomePhabricator

[MEX] M3.1.2 - Add publish functionality to edit forms
Open, Needs TriagePublic

Description

As a wikidata user
I want my edits made on mobile to be saved
So that I can actually contribute

A/C

  • User can enter in the simple text input (string)
  • qualifiers, references, and ranking remain read-only (functionality will be handled in T402618)
  • the publish button saves edits
  • the publish button only functions if the edits made are valid
  • When the user clicks publish the button becomes disabled, so the user doesn't bomb click it.
  • invalid edits (validation errors) are marked in the appropriate location in codex red
    • ( (!) I think this will be covered already in M3.1.1)
  • while we wait for the server to process the save, we remain on the dialog page
  • if successful
    • the user is redirected to the same location they were at previously (use the same functionality as in T401403)
    • the confirmation popup is displayed at the bottom of the page
    • the success popup is the codex component (and has a predefined time of how long it lasts on screen)
  • if the save is unsuccessful
    • the user remains on the edit statement dialog page
    • the appropriate error handling is used (for this ticket a placeholder is good enough, detailed error handling will be in T403011)
    • the user is informed of the unsuccessful save and given an informative reason as to why the save was unsuccessful
  • test are updated/created as needed

Open questions

  • Where/when/ for how long does the successful pop up appear?

ANSWER:
The codex component Message will appear when the publishing is successful or unsuccessful (component provides both actions). User stays in the page until the server returns an answer:
If successful: the user returns to the previous screen where he can admire his work and the success message shows up there.
If it fails: the user stays in the editing page, fail message appears on this page and explains reason of failure.

It should appear with a transition: Fade in (component option)

  • Where/when/ for how long does the unsuccessful pop up appear?

ANSWER:
Where - The position is not specified on the description on codex (or i couldn't find it). Therefore, if there is no predefined position, place it at the bottom of the page as in the prototype from Larissa that was user tested.
For how long: The component has an option called auto-dismiss that allows the component to disappear. The transition is pre-defined.

  • What happens between clicking “publish” and the server responding that the edit has been successfully saved? - - Do we show some kind of loading spinner? Do we close the edit form and wait until the server responds before showing the “succcess!” banner at the bottom? How do we display any errors the server might return (user blocked, AbuseFilter, etc.)?

ANSWER:
When the user clicks publish the button becomes disabled, so the user doesn't bomb click it.
The user stays in the editing page until the server responds positively or negatively.

A loading spinner will be added after first pass - UI refinement.

@karapayneWMDE & @Arian_Bozorg I suggest we create a ticket for all error behavior (extensive topic that should be handled consistently and holistically, and includes UX copy work.
T403011: [MEX] M3.1.2 - error handling while publishing/saving statement edits

Note: Adding qualifiers, references, and ranking will be handing in T402618: [MEX] M3.3 edit functionality for qualifiers, references, and ranking
0

Success popup

Screenshot 2025-09-12 at 11.04.24.png (1×1 px, 110 KB)

Figma file here

Related Objects

Event Timeline

karapayneWMDE renamed this task from [MEX] M3.4 edit functionality for ranking to [MEX] M3.5 edit functionality for ranking.Aug 22 2025, 7:49 AM
karapayneWMDE renamed this task from [MEX] M3.5 edit functionality for ranking to [MEX] M3 - title WIP 2.Aug 22 2025, 8:09 AM
karapayneWMDE renamed this task from [MEX] M3 - title WIP 2 to [MEX] M3.1.2 - Add publish functionality to edit forms.Aug 22 2025, 10:22 AM
karapayneWMDE updated the task description. (Show Details)
karapayneWMDE updated the task description. (Show Details)

Needed:

  • flow for how a successful publish/save looks
  • flow for how an unsuccessful publish/save looks

Rough outline for working on this task, as I see it so far (as a basis for further discussion):

  • disable “publish” button after you click it; for now, let’s also disable the “cancel” and “X” buttons
  • move the statement data to the store, so that the StatementGroupView can show the updated data after the EditStatementGroup is done and gone
  • tie the data currently being edited to the store – separately, not just modifying the existing data directly, so that upon canceling we can throw the edited data away and still show the previous (saved) data; probably some kind of “the currently edited statement group” store
  • ask the API to parse the value being edited (wbparsevalue), to perform server-side normalizations and bring it into the form in which we’ll want to save it
    • Wikibase desktop does this constantly as you edit the input (slightly debounced), which I think is generally a good idea – it means the parsed value is already available when we want to save the edit, which slightly speeds up the publishing
  • write a store action that makes an API request to edit the statement group with the new data, and wire that up to the “publish” button; any errors should just be logged to the console for now
  • when the API request returns, update the statement data store with the data returned by the server side (note: this is not necessarily exactly the data we sent! there might have been edit conflicts resolved server-side)
  • ask the API to format the value being edited (wbformatvalue) so we can display it afterwards
    • Wikibase desktop also does this constantly as you edit the input, and it also uses two formats (preview HTML and plain text), which I don’t think we need; we can do this either together with the wbparsevalue API call (mentioned above), or only after saving the edit
  • close the edit dialog and show the edited statement value in the statement view
  • show the “success” message sliding in from the bottom

And then some improvements for later:

  • pass a baserevid with the edit API request
    • I think it’ll make the most sense to track the base revision ID per statement group / property ID, i.e. after you save an edit to the P1 statements, the next edit to the P1 statements will use that edit’s revision ID as the baserevid, whereas an edit to the P2 statements will still use the initial revision ID from loading the page as the baserevid (until you reload the page)
  • don’t disable the “cancel” and “X” buttons during save, instead figure out what should happen in that case
  • maybe, if the user wants to save data, send the network requests to parse + format the value only when publishing the statement, rather than continuously as it’s being edited?
  • add a loading spinner while the statement is saving

Task Time

Task 1 - Edit Functionality, done in a series of small patches with continous review
Task 2 - Success + Unsuccessful Messages Components (unsuccessful = placeholder only, T403011 will handled the detailed version)
Task 3 - UI Refinement (to be completed after Task 1)