- (This includes browser testing)
|mediawiki/extensions/Wikibase||master||+621 -152||bridge: wire ErrorPermission into the ErrorWrapper|
|Open||None||T228066 Step 1: Error States of Data-Bridge [Tracking] (impact: medium)|
|Resolved||Tonina_Zhelyazkova_WMDE||T235154 show error when editor can't edit the statement because of permission errors on the repository|
|Resolved||• Pablo-WMDE||T237536 Wire up Permission Error Component in Error Component|
But what should happen in the off chance that multiple errors of different (top level) type occur? Example: The entity is protected on the repo & the property we asked to edit is not even part of the entity (technically called an INVALID_ENTITY_STATE_ERROR but this is just one example).
Should we show the other error along with the permission error(s)? Show only the permission error(s)? Does the generic error have precedence?
An answer to this question is complicated (only in practice, not in theory) a bit by the fact that we do not have an UX-approved generic error handler yet but only a make-shift one "An error occurred" (I suggest we take it as a placeholder for now to move around but naturally should pimp its visuals eventually).
Unless Charlie objects I would say the protection-related errors should have precedence because that's the part the user can potentially not easily fix and needs to be fixed first. Worst case if we do it the other way around the Item is protected and we send them to Wikidata just to find out there that they can't do anything.
@Pablo-WMDE let's go with lydia's suggestion. It makes the most sense
@Lydia_Pintscher we should think about how to prevent that error from happening though. ideally this is smth that the editor does not get confronted with since they can't do anything about it anyway. It would be better to let the template editors know, during template editing, that there is a mismatch of some sort but we can discuss this tomorrow.
I'm not sure about the skillset associated with the template editor persona (the one who would likely be the one to fix a suboptimal bridge link) but transporting information like this might be better suited (it can be complex) for a more technical channel like mw.log instead of investing time to build GUI for things which "should never happen".
This would also allow us to feed those occurrences, in the same/a similar format, back to a centralized logging system, to keep their number in check.
Ideas for T241126.