Page MenuHomePhabricator

don't show bridge edit pens when editor can't edit the article
Open, Needs TriagePublic

Description

As an admin on the client wiki I don't want editors who can't edit an article to have an easy way to edit the article by vandalizing on the repository in order to prevent vandalism creeping into my articles.

Problem:
When the article on the client is locked people can still vandalize it through the repository potentially. With the edit pens being the only visible edit actions in the article this is a very tempting option. We shouldn't make it so easy.

BDD
GIVEN an editor on the client
AND they don't have the rights to edit the current article
WHEN they view the article
THEN no bridge-enabled edit links are shown

Acceptance criteria:

  • edit pens are hidden when the current editor can't edit the current article
  • we only touch bridge-enabled edit links

Event Timeline

Restricted Application added a project: Wikidata. · View Herald TranscriptThu, Oct 10, 8:01 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The discussion in T231209 assumes that we do this via JS, by checking mw.config.get( 'wgIsProbablyEditable' ). But I think we can do this via CSS, depending on the mw-editable class on the surrounding body (added in T208315) – that CSS could either be part of the init module, or be added PHP-side so it doesn’t even have to wait for ResourceLoader. I think this would be more efficient and better for the user (no flash of unhidden edit buttons before we get around to hiding them).

In fact, it looks like this is exactly what mw-editable was added for? This code in eswiki:common.css looks very similar to what we’d want:

/*
 * Evitar que usuarios no confirmados se salten las semiprotecciones
 * a través de la edición en Wikidata: [[phab:T208315]], [[phab:T207648]].
 */
.wikidata-link {
  display:none;
}
body.mw-editable .wikidata-link {
  display:inline;
}

Except that we identify Wikidata Bridge links differently.

I think this would be more efficient and better for the user (no flash of unhidden edit buttons before we get around to hiding them).

Sounds good to me 👍

abian added a comment.Tue, Oct 15, 1:32 PM

In fact, it looks like this is exactly what mw-editable was added for?

That's right. :-)