[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

show error when editor can't edit the statement because of permission errors on the repository
Closed, ResolvedPublic13 Estimated Story Points

Description

As an editor on the client I want to be warned if I can't make an edit on the repository in order to not waste my time.

Problem:
The Item where the statement is coming from might be protected on the repository or the editor might be blocked. In this case we want to tell them that they can't edit the statement they are trying to edit.

We have 3 cases that can happen:

  • The item is fully protected
  • The item is semi-protected
  • The user is blocked on Wikidata

Screenshots/mockups:
more details in figma mock

Desktop - Fully protected

ItemFullyProtected (Desktop).png (488×500 px, 34 KB)

Desktop - Semi-protected

image.png (880×791 px, 90 KB)

Desktop - Blocked on repository

2. selected 1st message.png (488×500 px, 30 KB)

Mobile version (please note that typography switches to 16px size/24px line-height on mobile)

PermissionsRepo_Mobile.png (706×375 px, 40 KB)

(Blocked on client +) blocked on repo+ protected on repo

AllErrors.png (488×500 px, 23 KB)

AllErrors_DisplayOne.png (655×500 px, 42 KB)

Desktop - Cascade protection client

cascadeProtectionClient.png (562×500 px, 30 KB)

Desktop - Cascade protection repo

cascadeProtectionRepo.png (563×500 px, 29 KB)

Links in mocks

  • fully protected: $repourl/wiki/Project:Page_protection_policy
  • administrator(s): $repourl/wiki/Project:Administrators
  • protected: $repourl/wiki/Project:Page_protection_policy
  • protection log: $repourl/wiki/Special:Log/protect?page=Q$
  • editing disputes: $repourl/wiki/Project:Edit_warring
  • discuss this item: link to discussion page of respective item
  • semi-protected: $repourl/wiki/Project:Page_protection_policy
  • autoconfirmed/confirmed users: $repourl/wiki/Project:Autoconfirmed_users
  • log in: link to the client's log in page
  • create an account on $repoName: link to the client's account creation page (side-note from charlie: not sure about this one since editors might think that this is where they'll need to make the edits to get autoconfirmed but then still won't be able to edit since the auto confirmation happened on the wrong wiki)

BDD
GIVEN a protected Item
WHEN a user without the necessary edit rights tries to edit it in the bridge
THEN an error message is shown when opening the bridge
AND the edit can't be performed

GIVEN an editor that is blocked on the repository
WHEN they try to edit in the bridge
THEN an error message is shown when opening the bridge
AND the edit can't be performed

Acceptance criteria:

  • loading bar is replaced by error message as soon as possible (but abiding by the constraints listed in this ticket T232468) due to any of the reasons listed
  • the editability status depends on the Item the statement is coming from (which is not necessarily the one connected to the article via the sitelink)
  • These screens do not have a save button
  • The green-blueish side margin outlined on the specs must always be respected: margin sizes will not change due to text size changes
  • In case of triple error, notifications should be displayed following the order established by the designs: blockage on client + blockage on repo + item protection
  • Error notifications are accompanied by an expandable link component (find specs in WiKit): the link displays the error details on click/press
  • In case only a single message is displayed, then the expandable link is activated by default (error details are displayed) (See example "Desktop - Fully protected")
  • In case of a negative permission result (i.e. when showing the error(s)), the opening of bridge should not be tracked (as implemented in T231204).

Related Objects

StatusSubtypeAssignedTask
OpenNone
Resolved Tonina_Zhelyazkova_WMDE
ResolvedLucas_Werkmeister_WMDE
ResolvedMichael
ResolvedMichael
Resolved Matthias_Geisler_WMDE
ResolvedLucas_Werkmeister_WMDE
Resolved Matthias_Geisler_WMDE
Resolved Tonina_Zhelyazkova_WMDE
Resolved Pablo-WMDE
ResolvedLucas_Werkmeister_WMDE
Declined Matthias_Geisler_WMDE
Declined Matthias_Geisler_WMDE
ResolvedLucas_Werkmeister_WMDE
OpenNone
ResolvedLucas_Werkmeister_WMDE
ResolvedLucas_Werkmeister_WMDE
Resolved Pablo-WMDE
ResolvedLucas_Werkmeister_WMDE
ResolvedMichael
Resolved Pablo-WMDE
ResolvedLucas_Werkmeister_WMDE
ResolvedLucas_Werkmeister_WMDE
ResolvedLucas_Werkmeister_WMDE

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Questions about the messages:

  • Are $repoName and $clientName really links? If yes, to what URL?
  • What’s the URL for “templates and items”?
  • Why does “protection log” link to Special:ProtectedPages rather than Special:Log/protect?

Edit: “protection log” could also link to that particular item’s protection log, using Special:Log/protect?page=Q123

Another question that came up: "this value is currently semi-protected on $repoName and can be edited only be autoconfirmed/confirmed users", second from last mock-up.
This sounds like it iterates the groups that can. In practice we know about rights which need to be granted. Certainly we can try to deduce the groups from these but we'd put more effort into this than MediaWiki itself (uses fixed messages per "reason", e.g. "semi-protected"). Is that intended?

(Praise @Lucas_Werkmeister_WMDE for keeping our terminology consistent!)

Questions about the messages:

  • Are $repoName and $clientName really links? If yes, to what URL?

i was thinking we'd link them to the main pages of the projects but thinking about this more i don't see the point of having these be links. I'm gonna remove them.

  • What’s the URL for “templates and items”?

removed

  • Why does “protection log” link to Special:ProtectedPages rather than Special:Log/protect?

Edit: “protection log” could also link to that particular item’s protection log, using Special:Log/protect?page=Q123

good idea, let's do that!

Another thing I just realized…

If there are no relevant entries, the Item may have been moved after being protected.

Items can’t be moved :)

If there are no relevant entries, the Item may have been moved after being protected.

Items can’t be moved :)

I removed the sentence from I3dcd49dd4c, but @Michael pointed out that the item may have been merged. I think that’s indeed possible, so I guess I should add the sentence back, but saying “the Item may have been merged into a protected Item”?

(Actually, I’m not sure if we would get an error in that case… I think we don’t really handle redirects yet, in general?)

If there are no relevant entries, the Item may have been moved after being protected.

Items can’t be moved :)

I removed the sentence from I3dcd49dd4c, but @Michael pointed out that the item may have been merged. I think that’s indeed possible, so I guess I should add the sentence back, but saying “the Item may have been merged into a protected Item”?

(Actually, I’m not sure if we would get an error in that case… I think we don’t really handle redirects yet, in general?)

Is this something you have to find out first? Otherwise if there's no error state, it would be great if you coudl file a ticket for that in general and for now leave the sentence out of the bridge.

There are differences between the mocks in this ticket and the corresponding ones in Figma.
What I noticed so far:

  • the expand area now says "See details" and the icon is different
  • The sentence "This value, is currently fully protected on $repoName and can be edited only by administrators." used to be bold and now it is not.

Depending on which ones are correct I will or will not make changes to my current task and -1 or +1 Lucas's patch. So I think we should make a decision ASAP as this is in the current sprint.

@Charlie_WMDE @SaraiSan

(Actually, I’m not sure if we would get an error in that case… I think we don’t really handle redirects yet, in general?)

Is this something you have to find out first? Otherwise if there's no error state, it would be great if you coudl file a ticket for that in general and for now leave the sentence out of the bridge.

I tried it out, and if the target item is a redirect, we’ll get an error when opening the bridge (“Result does not contain relevant entity.”). So I guess we can leave the sentence out for now, and I’ll file a task for handling redirects(?) – edit: T240463

(Actually, I’m not sure if we would get an error in that case… I think we don’t really handle redirects yet, in general?)

Is this something you have to find out first? Otherwise if there's no error state, it would be great if you coudl file a ticket for that in general and for now leave the sentence out of the bridge.

I tried it out, and if the target item is a redirect, we’ll get an error when opening the bridge (“Result does not contain relevant entity.”). So I guess we can leave the sentence out for now, and I’ll file a task for handling redirects(?) – edit: T240463

yes, thank you!

There are differences between the mocks in this ticket and the corresponding ones in Figma.
What I noticed so far:

  • the expand area now says "See details" and the icon is different
  • The sentence "This value, is currently fully protected on $repoName and can be edited only by administrators." used to be bold and now it is not.

Depending on which ones are correct I will or will not make changes to my current task and -1 or +1 Lucas's patch. So I think we should make a decision ASAP as this is in the current sprint.

@Charlie_WMDE @SaraiSan

@Tonina_Zhelyazkova_WMDE are you unblocked on this?

There are differences between the mocks in this ticket and the corresponding ones in Figma.
What I noticed so far:

  • the expand area now says "See details" and the icon is different
  • The sentence "This value, is currently fully protected on $repoName and can be edited only by administrators." used to be bold and now it is not.

Depending on which ones are correct I will or will not make changes to my current task and -1 or +1 Lucas's patch. So I think we should make a decision ASAP as this is in the current sprint.

@Charlie_WMDE @SaraiSan

@Tonina_Zhelyazkova_WMDE are you unblocked on this?

Yes, we're taking Figma as the source of truth, as we agreed yesterday.

There are differences between the mocks in this ticket and the corresponding ones in Figma.
What I noticed so far:

  • the expand area now says "See details" and the icon is different
  • The sentence "This value, is currently fully protected on $repoName and can be edited only by administrators." used to be bold and now it is not.

Depending on which ones are correct I will or will not make changes to my current task and -1 or +1 Lucas's patch. So I think we should make a decision ASAP as this is in the current sprint.

@Charlie_WMDE @SaraiSan

@Tonina_Zhelyazkova_WMDE are you unblocked on this?

Yes, we're taking Figma as the source of truth, as we agreed yesterday.

oki doke. just wanted to make sure :)

Another question that came up: "this value is currently semi-protected on $repoName and can be edited only be autoconfirmed/confirmed users", second from last mock-up.
This sounds like it iterates the groups that can. In practice we know about rights which need to be granted. Certainly we can try to deduce the groups from these but we'd put more effort into this than MediaWiki itself (uses fixed messages per "reason", e.g. "semi-protected"). Is that intended?

To tie this one up – if I recall correctly, we agreed with Lydia that it’s fine to just say “autoconfirmed” (hard-coded into the message, without “/confirmed”), since MediaWiki does this as well (semiprotectedpagewarning). Wiki admins who want the text to be fully accurate can override it on their wiki to mention additional groups.


We also seem to be missing mocks for cascade-protected pages. This can come from two ends: the repo, and the client. (Sadly, the edit links aren’t hidden on cascade-protected client pages.)

On the repository wiki, cascade protection of the item might be theoretically possible (I haven’t tried it out), but on Wikidata in particular, the list of cascade-protected pages lists only one single page, which hasn’t been edited since 2013 and doesn’t transclude anything else. I think it’s safe to say that we don’t use cascade protection on Wikidata.

On client wikis, cascade protection doesn’t seem to be all that popular either. English Wikipedia has 124 cascade-protected pages that aren’t directly protected, none of them in the main namespace (Quarry); German Wikipedia has 1949 such pages, all of them in the project namespace (Quarry); Commons has 404 such pages, in the Project and File namespaces; on French, Russian and Basque Wikipedia, I found no such pages at all. If you also search pages that are otherwise protected, you find a grand total of six pages in the main namespace on English Wikipedia, and not much more on the other wikis I checked.

I’m not sure where I’m going with this, to be honest… we should still handle these errors somehow (and I guess the cascade-protected files on Commons are the most realistic case where users would encounter them), but not lose too much sleep over it?

  • log in: link to the client's log in page
  • create an account on $repoName: link to the client's account creation page (side-note from charlie: not sure about this one since editors might think that this is where they'll need to make the edits to get autoconfirmed but then still won't be able to edit since the auto confirmation happened on the wrong wiki)

Should these really point to the client even though the surrounding text talks about the repo?

Change 558150 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: dispatch permission check on BRIDGE_INIT

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

How will permission violations affect the opening tracking as implemented during T231204: track Bridge openings by property datatype? /cc @Lydia_Pintscher

Talking with Lydia: "don't count it" (i.e. do not perform the opening tracking in case of opening error).

Change 559515 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: move data type tracking into BRIDGE_INIT

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

Change 559515 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: move data type tracking into BRIDGE_INIT

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

What’s the current status on cascade-protected messages? As far as I’m aware, the completion of T237526 is still blocked on them.

Observation: Devs during task break-down coined the term EditChoice. The product doc glossary already mentions "Edit decision" - we should decide for one or the other term to avoid confusion (especially as there already is the distinction from "Edit flow").

On client wikis, cascade protection doesn’t seem to be all that popular either. English Wikipedia has 124 cascade-protected pages that aren’t directly protected, none of them in the main namespace (Quarry); German Wikipedia has 1949 such pages, all of them in the project namespace (Quarry); Commons has 404 such pages, in the Project and File namespaces; on French, Russian and Basque Wikipedia, I found no such pages at all. If you also search pages that are otherwise protected, you find a grand total of six pages in the main namespace on English Wikipedia, and not much more on the other wikis I checked.

One example of pages protected via cascade protection on English Wikipedia are the “on this day” pages, e. g. Wikipedia:Selected anniversaries/January 8 (you’ll have to adjust the date if you want to see the cascade protection in action later).

Change 562796 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[mediawiki/extensions/Wikibase@master] Remove IP address from i18n messages

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

Change 562796 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Remove IP address from i18n messages

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

@Lucas_Werkmeister_WMDE @Tonina_Zhelyazkova_WMDE i added the mocks for the cascade protection to the task description. measurements etc can be found in the figma file under the same link as the other ones. If there's any questions, let me know!

NOTE: text of the cascade protection mocks was changed in the figma file. i have not updated the mocks in the ticket. please refer to the figma file for the newest copy. I will always give notice when text has been changed.

/cc @Lydia_Pintscher

Change 566258 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: remove resolved TODO from test

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

Change 566258 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: remove resolved TODO from test

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

Change 567089 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: refactor ErrorPermissionInfo

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

Moving back to Doing because the only currently attached change is marked WIP in Gerrit, so I don’t see what I could review at the moment.

Intermediate state (how a repo item permission error currently looks like on my system) integrated into MW:

Bildschirmfoto von 2020-01-27 17-28-00.png (1×1 px, 346 KB)

Provisional list of todos:

  • "You do not have permission to edit this value, for the following reasons:"
    • vertical spacing
  • "More details" link
    • vertical spacing
    • might be bold in the mocks
  • "Why is this value protected?" / "What can I do?" headlines
    • vertical spacing
  • "Why is this value protected?" list
    • list-style-position, padding left
    • item vertical spacing
  • all links
    • link/hover color, text decoration

Change 567876 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] ErrorPermission: fix content spacing

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

Change 567089 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: refactor ErrorPermissionInfo

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

Change 567876 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] ErrorPermission: fix content spacing

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

how and where can I test the different options? I will probably also need to be blocked of repo/client to test the different versions

Notes from verification (subtasks to be created):

  • missing line-spacing on general “you can’t edit this value for the following reasons” message
  • cascade protected on client and repo has $2 in “administrators” link
  • we don’t load the mediawiki.jqueryMsg ResourceLoader module!

image.png (450×500 px, 95 KB)

how it looks in my browser on german beta

I created three subtasks (Phabricator doesn’t show them here for some reason): T243917, T243918, T243919.

Charlie_WMDE moved this task from Verification to Done on the Wikidata-Bridge-Sprint-13 board.

looks good to me!\o/