Page MenuHomePhabricator

๐ŸŒ๏ธ Modify data of item
Open, Needs TriagePublic13 Estimated Story Points

Description

As a developer I want to be able to edit an entire Wikidata item in one go.

PATCH /entities/items/{item_id}

Request payload

{
  "patch": [
    {
      "op": "",
      "path": "",
      "value": ""
    }
  ],
  "tags": (optional),
  "bot": (optional),
  "comment": (optional)
}

Response to be same as POST /items

Acceptance criteria

  • Request includes a JSON Patch document describing wanted changes
    • client can provide additional edit metadata: mediawiki tags, edit summary text to append to the automated summary, and a bot edit flag, like in PATCH /entities/items/{item_id}/statements/{statement_id}
  • Response to a success request will include the new item data, including the ETag (revision ID) and modification timestamp
  • "Automated edit summary":
    • if only sitelinks and/or statements were modified, use /* wbeditentity-update:0| */
    • if only labels, descriptions and/or aliases were modified, use the same edit summaries as for patching labels, descriptions or aliases, but combining the modified languages across all three fields (see e.g. T332739), i.e. /* wbeditentity-update-languages-short:0||LANGS */ if labels/descriptions/aliases in 50 or fewer languages were modified, and /* wbeditentity-update-languages:0||LANG_COUNT */ if more than 50.
    • if both labels/descriptions and/or aliases and also statements and/or sitelinks were modified, use wbeditentity-update-languages-and-other-short instead of wbeditentity-update-languages-short, and wbeditentity-update-languages-and-other instead of wbeditentity-update-languages
  • Handle HTTP conditional request headers as in PATCH /entities/items/{item_id}/statements/{statement_id}
  • Handle user authentication/authorization like in PATCH /entities/items/{item_id}/statements/{statement_id}

Error cases to consider

HTTP response coderesponse payload
Item does not exist 404"code": "item-not-found"
"message": "Could not find an item with the ID: {item_id}"
Invalid item ID 400"code": "invalid-item-id"
"message": "Not a valid item ID: {item_id}"
Invalid edit tag400"code": "invalid-edit-tag"
"message": "Invalid MediaWiki tag: {tag}"
Edit comment/summary too long400"code": "comment-too-long"
"message": "Comment must not be longer than {limit} characters"
Request would change the ID of the item422"code": "patched-item-invalid-operation-change-item-id"
"message": "Cannot change the ID of the existing item"
Missing a mandatory field in JSON Patch (e.g. "path", "op")400"code": "missing-json-patch-field"
"message": "Missing '{field}' in JSON patch"
"context": { "operation": { <PATCH_OBJECT> }, "field": <MISSING_FIELD> }
Operation in the JSON Patch is not valid400"code": "invalid-patch-operation"
"message": "Incorrect JSON patch operation: '{op}'"
"context": { "op": "{op}", path": "/some/path" }
Value provided in the JSON Patch operation is of incorrect type400"code": "invalid-patch-field-type"
"message": "The value of '{field}' must be of type string"
"context": { "operation": { <PATCH_OBJECT> }, "field": <FIELD> }
Provided JSON Patch document is not valid (generic error)400"code": "invalid-patch"
"message": "The provided patch is invalid"
Cannot apply JSON Patch as target path not found409"code": "patch-target-not-found"
"message": "Target '{target}' not found on the resource"
"context": { "operation": { <PATCH_OBJECT> }, "field": <PATH> }
Test operation of JSON Patch failed409"code": "patch-test-failed"
"message": "Test operation in the provided patch failed. At path '{path}' expected '{expected}', actual: '{actual}'"
"context": { "operation": { <PATCH_OBJECT> }, "actual-value": <ACTUAL> }
Request payload is not JSON415"code": "unsupported-content-type"
"message": "Unsupported Content-Type: '{content_type}'"
Value in the item data after changes is invalid422"code": "patched-item-invalid-field"
"message": "Invalid input for '{field}' in the patched item"
"context": { "path": "{field}", "value": "{value}"}
Unexpected field for item in patch request422"code": " patched-item-unexpected-field"
"message": "The patched item contains an unexpected field: {"field"}"
Statement id cannot be added or changed422"code": "statement-id-not-modifiable"
"message": "Statement IDs cannot be created or modified"
Redirected item409"code": "redirected-item"
"message": "Item {item_id} has been merged into {other_id}"
Invalid statement group object422 "code": "patched-invalid-statement-group-type"
"message": "Not a valid statement group"
"context": { "path": "{property_id}" }
Invalid statement object422 "code": "patched-invalid-statement-type"
"message": "Not a valid statement type"
"context": { "path": "{property_id}/{index}" }
Statement's Property ID value does not match the key of the statement group422 "code": "patched-statement-group-property-id-mismatch"
"message": "Statement's Property ID does not match the statement group key"
"context": {
"path": "{property_id_key}/{index}/property/id",
"statement-group-property-id": "{property_id_key}",
"statement-property-id": "{property_id_value}"
}

PATCH sitelink specific errors: https://doc.wikimedia.org/Wikibase/master/js/rest-api/#/sitelinks/patchSitelinks (everything under 422)
PATCH labels specific errors: https://doc.wikimedia.org/Wikibase/master/js/rest-api/#/labels/patchItemLabels (everything under 422, follow the context similar to POST /item).
PATCH description specific errors: https://doc.wikimedia.org/Wikibase/master/js/rest-api/#/descriptions/patchItemDescriptions (everything under 422, follow the context similar to POST /item).
PATCH aliases specific errors: https://doc.wikimedia.org/Wikibase/master/js/rest-api/#/aliases/patchItemAliases (everything under 422, follow the context similar to POST /item)
PATCH statements specific errors: https://doc.wikimedia.org/Wikibase/master/js/rest-api/#/statements/patchItemStatement (under 400: change id and change property, under 422, under 409)

Possibly relevant pointers:

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
ResolvedMuhammad_Yasser_Jazirahly_WMDE
ResolvedMuhammad_Yasser_Jazirahly_WMDE
ResolvedDima_Koushha_WMDE
OpenDima_Koushha_WMDE
OpenOllie.Shotton_WMDE
OpenDima_Koushha_WMDE
OpenNone
OpenNone
OpenNone
OpenNone
OpenSilvan_WMDE
OpenMuhammad_Yasser_Jazirahly_WMDE
OpenDima_Koushha_WMDE
OpenNone
OpenNone

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptJul 28 2023, 2:08 PM
Ifrahkhanyaree_WMDE renamed this task from Modify data of item/property to Modify data of item.Sep 26 2023, 12:25 PM
Ifrahkhanyaree_WMDE updated the task description. (Show Details)
Silvan_WMDE renamed this task from Modify data of item to ๐ŸŒ๏ธ Modify data of item.Wed, May 15, 2:29 PM

Hello @Dima_Koushha_WMDE @Jakob_WMDE @Ollie.Shotton_WMDE @Silvan_WMDE
I tried to draw a dependency diagram for this story using draw io, and it's like this:

dependencies-diagram-patch-item.drawio.png (891ร—1 px, 142 KB)

There would be 6 stages for subtasks:
1- The first stage would be the beginning, with adding the new endpoint to OAS and trying to practice versioning.
2- The second stage would be the happy path, which will have the validation and deserialization in it without error handling and will depend on adding the route to OAS for e2e tests to pass.
3- The third stage would be all the subtasks that can't exist without the happy path.
4- The fourth stage would consist of:

  • middleware subtask which will depend on the authorization patch.
  • the post-patch validation patches which will depend on the first post-patch validation patch (the top-level one) and will add the validation to the same validation file.

5- After completing all previous stages, the spec tests will be added.
6- As a last step, we would mark the endpoint as production-ready and practice versioning after changing the OAS document.

The diagram file: https://drive.google.com/file/d/1RJOyHTF-xV_9OfhNtAxy5-EnawNfI7CI/view?usp=sharing

Hello @Ifrahkhanyaree_WMDE

While working on adding the new endpoint to OAS I found that the context for labels, descriptions, and aliases is requested to follow the context similar to POST /item and not similar to the PATCH endpoints for the related term.

I think that maybe having the same context for patching item labels in the main item PATCH endpoint or in the item labels PATCH endpoint is a good idea? since nothing was different for the patched labels inside that item other than changing the endpoint. What do you think?

Ah, I mean like the additional error context that has to be added as we did for the POST /items since it's the full item and not just a specific label in one item but from the first quick check it seems that all those cases are covered in PATCH.

I can just remove the "keep as POST" sentence