Problem: when users attempt to edit a protected file page, they only find out after they've made edits and when they are about to publish them, they find out those changes won't be accepted because the file is protected. We want to tell users up front that a file is protected so as to not waste their time/energy.

Here are some options we can consider in solving for this problem:

Option 1

Treat panels like protected file pages are being treated already, where the user is informed that the page is protected after engaging Edit mode.

Captions

Read mode

(no change)

Edit mode

The standard messaging displays in Edit mode

Statements

Read mode

Search field is unable to be interacted with

Edit mode

The standard messaging displays in Edit mode

Option 2

Save users a click and show a popover/tooltip when hovering, but just show a brief reason why this is protected.

Captions

Statements

Option 3

Hybrid solution - let users know ahead of time, but also give more information should a user select Edit.

Captions

Read mode

Edit mode

Statements

Read mode

Edit mode

@Ramsey-WMF pinging for input/acceptance criteria

Memorializing a conversation Pam and I just had:

• We'll go for a thin banner at the top of each tab
• The banner will serve as a notice both about Structured Data editing not being possible, but also as a heads up for Wikitext editing (current design doesn't inform the user until they've already tried to edit the page or section)

• On Structured Data panels, Edit buttons should not be present on locked files. Additionally, Make Prominent should also be absent and any auto-suggest entity boxes or other input methods should be disabled

Made updates, and will be sharing them with the design team for feedback on visual design and style guide adherence: https://wikimedia.invisionapp.com/freehand/document/lZtXyDYNZ

Per our design:dev chat earlier today, this is the direction we're going in. The templates already in use will show in between the tabbed navigation bar and the rest of the content on the page. Messaging remains regardless of selected tab.

(The mocks are using the tab design currently being worked out in this ticket T215644)

This is actually a regression, the tab at the top of the page should say "View source", not "Edit". (Granted that still wouldn't meet "obvious and understandable".) Probably related to MCR and/or how Wikibase customizes the "edit" action.

Hey @PDrouin-WMF, I've got a couple of clarifying questions for you:

1. Do I need to account for other types of protection? It looks like the types that might apply here are full protection, semi-protection, and cascading protection (pictured in your mock).
2. In addition to showing the protection message, do we want to remove or disable the "Edit" links for captions and structured data when a user is prohibited from editing?

With respect to the tab at the top of the page as mentioned by @Tgr : this tab correctly shows "view source" when I'm an anon or non-admin user viewing a protected file on my local MediaWiki instance, but it does show "edit" on the live Commons site. I'm assuming that issue is outside the scope of this task since it doesn't involve our extension, but someone please correct me if I'm wrong on that.

Hi @AnneT! I can answer #2. Yes, we would want to disable the Edit link. I know these mocks are old and don't show the Edit link at all, but I think showing that the Edit link is disabled is good additional context for users.

As to #1, that I am not sure. @Ramsey-WMF might have more info?

Do I need to account for other types of protection? It looks like the types that might apply here are full protection, semi-protection, and cascading protection (pictured in your mock).

You are correct. Full, Semi, and cascading are what we're looking to account for here.

Awesome, thanks to you both!

Change 530617 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Add protection message to structured data tab

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

Hey @Ramsey-WMF, could you help me understand if it's better to use existing templates like this one or to recreate them within our extension? I'm not sure if it's important for an admin to be able to edit a template/message like cascadeprotected and see the changes reflected downstream, including within the structured data UI.

Basically, if we reuse the templates, the code gets pretty hacky due to the way templates are parsed, but if we create our own messages they might eventually diverge from the messages/markup/styles in the existing templates. Mark has also mentioned that it's sometimes advantageous to create a new message vs. reusing one since the contexts may be different, particularly in other languages, so that's another factor. I'm hoping by providing some context on how admins use these messages you can help me decide which way to go.

Happy to chat more in Slack or Hangouts if it's easier. Thanks!

Hello @AnneT

These are good questions! But I think, for now at least, we have to lean toward using existing templates for a few reasons:

1. It's too early to introduce yet another thing that Commons admins will have to edit and keep track of (new, SDC-specific templates). Admins have enough work to do as it is, and we don't yet have established community practices that would warrant a custom approach
2. Structured Data is a really new thing and Commons users still don't know exactly what it is or what it means. Custom messages could potentially add to the confusion.
3. For this specific case (the file is protected), I think the existing messaging is fine and we doesn't require any SDC-specific language. Future use cases might require mediainfo-specific messaging, or they might not, but we don't have enough information at the moment to plan ahead so it's probably best to stick with what's there.

All of that makes sense, thanks for your input @Ramsey-WMF!

Change 531696 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/WikibaseMediaInfo@master] Tests: Add unit tests for getProtectionMsg

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

Change 531711 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Tests: Add test coverage for userCanEdit()

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

Change 530617 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Add page protection message to file page

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

Change 531696 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Tests: Add unit tests for getProtectionMsg

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

Change 531711 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Tests: Add test coverage for userCanEdit()

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