Page MenuHomePhabricator

UI for annotations
Closed, ResolvedPublic

Description

Details TBD. Annotation data will need to be rendered on the toolinfo detail screen for sure. There may or may not be annotations that also end up on summary cards. Editing likely will be done starting from the toolinfo detail screen.

Event Timeline

bd808 triaged this task as Medium priority.Apr 11 2021, 9:31 PM

I have gotten far enough in building this out that I have new questions about how manipulating annotations should look from the audit log and edit history points of view.

@Slst2020, @Raymond_Ndibe, and I talked this through today in a conference call. We came to the basic conclusion that Toolhub end users (people using our UI) should see edits to the "core" Tool model and edits to an associated Annotations model as being the same type of action. The differentiation between the two activities is an artifact of how we are enforcing access controls on the backend; it is not a material difference otherwise. What does this mean in practice?

  • Fetching a toolinfo record via GET /api/tools/{name}/ should return the combined tool + annotations data.
  • Results from GET /api/search/tools/ should return the combined tool + annotations data.
  • The /api/tools/{tool_name}/revisions/* family of endpoints (including diffs) should operate on the combined tool + annotations data.
    • This by extension should make the revisions, diffs, and patrolling actions work the same for either type of edit.
  • Audit log entries should look the similar in the UI for an edit of either model and both lead to the tool details.
  • Editing in the UI should use the same "edit" button for both types of edits with the distinction of how to persist the changes to the two types being handled by our UI business logic.

T303661: [Spike] Figure out how to compute facets across multiple fields is about figuring out the backend tech needed to have fields in the annotation layer which backfill data that could be in the main toolinfo record, but has not be provided there for various reasons (the most likely of them being that the toolinfo author doesn't know about the newer toolinfo.json schemas yet). I don't think it makes sense to allow all fields introduced after the toolinfo.json 1.0.0 spec this way, but here are some I do think could be beneficial:

  • deprecated
  • replaced_by
  • experimental
  • for_wikis
  • icon
  • available_ui_languages
  • tool_type
  • api_url
  • developer_docs_url
  • user_docs_url
  • feedback_url
  • privacy_policy_url
  • translate_url
  • bugtracker_url

Change 771434 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):

[wikimedia/toolhub@main] ui: Refactor Tool Edit Form

https://gerrit.wikimedia.org/r/771434

Change 771434 merged by jenkins-bot:

[wikimedia/toolhub@main] ui: Refactor Tool Edit Form

https://gerrit.wikimedia.org/r/771434

Change 775303 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):

[wikimedia/toolhub@main] ui: implement edition and viewing of tool annotations data

https://gerrit.wikimedia.org/r/775303

Change 775303 merged by jenkins-bot:

[wikimedia/toolhub@main] ui: implement editing and viewing of tool annotations data

https://gerrit.wikimedia.org/r/775303

Change 786342 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production

https://gerrit.wikimedia.org/r/786342

Change 786342 merged by jenkins-bot:

[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production

https://gerrit.wikimedia.org/r/786342