2022-05-21 17:09:31 JJMC89 bd808: why after https://toolhub.wikimedia.org/tools/pywikibot/history/revision/17732/diff/24666 do I not see that edit reflected when I click edit tool? 2022-05-21 17:19:00 +bd808 JJMC89: I think we actually have a little bug/misfeature at the moment that the owner of a toolinfo record cannot edit the annotations layer. That's where and how Saint-Vandora is making those edits.
Description
Description
Details
Details
Related Objects
Related Objects
Event Timeline
Comment Actions
This appears to extend to other cases. I do not see the edits from https://toolhub.wikimedia.org/tools/infobox-export/history/revision/17766/diff/24684 in https://toolhub.wikimedia.org/tools/infobox-export/edit.
Comment Actions
This is another annotation change. Basically if you have the ability to edit a "core" record either because you are the owner of it or because you have the admin right, you currently have no way to see or change the "annotations" on that same record in an edit form.
Why this happens is that in EditToolOrAnnotations.vue we branch:
<template> ⠀⠀⠀<v-container> ⠀⠀⠀ ⠀⠀⠀<EditTool ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀v-if="tool_schema && toolFromVuex && $can( 'change', tool )" ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀v-model="tool" ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀:tool-schema="tool_schema" ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀:annotations-schema="annotations_schema" ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀:links="links" ⠀⠀⠀ ⠀⠀⠀/> ⠀⠀⠀ ⠀⠀⠀<EditAnnotations ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀v-else-if="annotations_schema && ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀toolFromVuex && ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀!$can( 'change', tool ) && ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀$can( 'add', 'toolinfo/annotations' )" ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀v-model="tool" ⠀⠀ ⠀⠀⠀ ⠀⠀⠀:schema="annotations_schema" ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀:links="links" ⠀⠀⠀ ⠀⠀⠀/> ⠀⠀⠀ ⠀⠀⠀<v-row> ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀<v-col cols="12"> ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀<ScrollTop /> ⠀⠀⠀ ⠀⠀⠀ ⠀⠀⠀</v-col> ⠀⠀⠀ ⠀⠀⠀</v-row> ⠀⠀⠀</v-container> </template>
When the user has the right to change the tool they get the "core" edit UI, otherwise they get the "annotations" edit UI. This branching is fine, but the user with rights to edit the core is currently missing a way to edit annotations as well.
Comment Actions
When the user has the right to change the tool they get the "core" edit UI, otherwise they get the "annotations" edit UI. This branching is fine, but the user with rights to edit the core is currently missing a way to edit annotations as well.
Shouldn't this be the right approach? given a tool owner the UI to edit annotations as well as core records seems like information overload (and maybe unnecessary), since at the end, the core records will still take precedence over the annotation records.
This approach was basically taken because of the need to make the whole UI seamless and hide the fact that a non tool owner is not editing the core record but rather the annotations record from them.
If the tool owner doesn't like the content of the annotations record, filling the same field in the core record should suffix, because unless someone tries playing with the API, there is really no way to know the difference through the UI, and the core record always overwrites the annotation record in the UI
Comment Actions
the core records will still take precedence over the annotation records.
If the tool owner doesn't like the content of the annotations record, filling the same field in the core record should suffix, because unless someone tries playing with the API, there is really no way to know the difference through the UI, and the core record always overwrites the annotation record in the UI
This doesn't work when the field should be empty (e.g. because it does not apply or is not appropriate for the tool).
Also, as an admin, I sometimes (I think it is the cases where the tool was added by a method other than via import.) cannot remove (inappropriate/incorrect) content added in annotations.
Comment Actions
A partial revert by editing the annotations was the action that I realized not only that the owner of the toolinfo record could not do, but also cannot currently be done via the UI by an admin either. I do understand the desire to make things less complicated for the users, but we have ended up inventing a data layer where the only way to fix bad edits is by having an alternate Wikimedia account that has no Toolhub privileges. This is exacerbated by whatever I did wrong in the backend that is causing T308935: Undo doesn't completely revert edits (annotations not undone by "undo" basically).
Comment Actions
I think a reasonable improvement here would be to expose a second edit button leading to EditAnnotations.vue to folks who hold the $can( 'change', tool ) permission.
The changes in https://gerrit.wikimedia.org/r/c/wikimedia/toolhub/+/785973 are a partial solution for this in that they pre-populate empty core fields with corresponding annotations values. Those values will then be stored in the core record on save. This does not completely suffice for a few reasons.
First, while this prompts the record owner to correct vandalized/unwanted values, it does not remove or overwrite the annotation data on write. This could leave harmful vandalism in the record without a way for privileged users to remove it. It won't show in the view screens because of the higher precedence of core record values. It still however will show when non-privileged users use the edit form. And it will show for every direct use of the API which we actually hope becomes more common in the future.
Additionally, this cannot address the "should be unset/empty" cases mentioned by @JJMC89 in T308934#7951914. We have seen actual need for this in the deprecated and obsolete flags in production data. Non-maintainers can and have set these flags on arbitrary records, which we actually want to allow, but once set the annotation's truthy value cannot be overridden by adding a falsey value in the core record. This is at least partially because the backend storage will add falsey values on save even when the input does not contain a key=value pair for the field. That would prevent us from ever showing a boolean annotation contrary to the use case requirements.
We have all the business logic needed to edit annotations, so the change is basically adding a button to the UI. For the vast majority of user and toolinfo combinations only one button, the "edit annotations" button would be shown. For the combinations where the user has elevated rights (sysop) and/or was the person who created the record initially a second button would be shown allowing editing the core record. Because the annotation edit use case is much more common I think we should just call that "Edit" in the UI. The current "Edit Tool" label can be used for the core edit use case.
Comment Actions
Change 865797 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):
[wikimedia/toolhub@main] ui(edit): Add distinct edit buttons for core and annotations
Comment Actions
Change 865797 merged by jenkins-bot:
[wikimedia/toolhub@main] ui(edit): Add distinct edit actions for core and annotations
Comment Actions
Change 868183 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):
[operations/deployment-charts@master] toolhub: bump container to 2022-12-14-185830-production
Comment Actions
Change 868183 merged by jenkins-bot:
[operations/deployment-charts@master] toolhub: bump container to 2022-12-14-185830-production