What wiki is this? This is an optional feature that must not be turned on there.

mpdelbuono wrote:

This was filed for enwiki.

This would at least need consensus then (for this feature and having templates be reviewable).

(In reply to comment #2)

This was filed for enwiki.

Sounds like a SiteRequest then

Indeed. I was unaware that code to do this already existed when I filed the bug.

Based on this comment from Whatamidoing on en.wp, it appears that the code doesnt currently do what is desired.

https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)&diff=588580250&oldid=588562289

Given that, changing back to a bug against FlaggedRevs.

I don't known if this is related or a different bug, but a recent edit on a ns:MediaWiki transcluded page has partially broken the system:

https://pt.wikisource.org/w/index.php?title=Archivo_nobiliarchico_brasileiro/Abadia_(1º_Barão_de)&oldid=223504&diff=cur&uselang=en

ns:MediaWiki isn't set to be validadet using FlaggedRevs, but ns:0, some custom namespaces and ns:Template is set to.

I've tried looking into this.
The flaggedtemplates and flaggedimages tables are used as a sort of cache to avoid querying each and every included template / images for its stable version (which would be inefficient). But these are populated during reviews and autoreviews. On unreviewable pages, we could only populate them during edits.
So this seems feasible to me, but only for pages that have been edited since after the feature gets enabled (or a maintenance script is run).
This could be of significant benefit against template vandalism, which again made a big splash recently, though there should probably be consensus for such a feature on enwiki for it to be developed.

@Cenarium At enwiki as far as I know, the template namespace doesn't seem to allow turning flagged protection on. As for transclusion of unreviewed pages, the issue seems known by VPT, but since stronger flavors of flagged protection don't officially have consensus yet, this hasn't been a big problem.

@andymw FlaggedRevs can only be enabled in main or project namespace at enwiki for now.
There has been an increase in the support for pending changes lately, it looks like the related deferred changes will easily and almost uncontroversially achieve consensus.
So I think we should try to revisit the issue at some point, to see if there's consensus for use in template space (which would be a motivation to fix this bug).

Actually, the db can be populated during LinksUpdate so it should be feasible for all pages.

There are articles that transclude sections of other articles (#section-h and <onlyinclude>, etc, see https://en.wikipedia.org/wiki/The_Fast_and_the_Furious). Pretty sure the sections that get transcluded will be the latest revision despite possible unreviewed changes, which seems to be a problem.

A malicious scenario, if I understand correctly: an unregistered user makes an unreviewed change on a flaggedrevs protected article, then transcludes the whole article somewhere else. This allows the latest changes to be shown for that page despite FlaggedRevs in place

I've tested labelled section transclusion on stable pages and it works fine, there's no reason it won't work on non-stable pages. There are some limitations of the feature, but this has to do with situational inclusions, see FlaggedRevs.php (FR_INCLUDES_STABLE).
As for the scenario, if the user needs to edit the target page, it wouldn't really matter that they can transclude pending changes.

@Cenarium the results I'm getting (testing with a non-reviewer account in tandem). In all cases, page B has unreviewed edits. Suppose the unreviewed edit on page B is in section "Foo".

1. Transclude B onto non-PC-enabled page A: unreviewed changes of B are seen when viewing A logged out.
2. Transclude B onto PC-enabled page A generating an unreviewed change for A, then later this change is reviewed: unreviewed changes of B are seen when viewing A logged out.
3. Substitute B onto non-PC-enabled page A: contents of what's being substituted were from the latest unreviewed version of B, and the public sees this.
4. Substitute B onto PC-enabled page A generating an unreviewed change for A, then later this change is reviewed: contents of what's being substituted were from the latest unreviewed version of B, and the public sees this.
5. Use #section-h to transclude section B onto page A. The contents of the section that's transcluded is from the latest revision of B. If A has no unreviewed edits, these changes are live.

Does this ticket address all 5 discrepancies, or just 1, 2, and 5? (I'm not sure what the correct behavior of 3 and 4 are, but for templates meant always to be substituted but has an unreviewed edit, it's unclear whether the substituted text should be from the latest revision or the latest accepted revision.)

@Cenarium Another question. For a heavily transcluded page, is it the unreviewed edit that's meant to be the "heavy" action that adds to the job queue, or the act of accepting (unaccepting) the edit (meant to make the change go live) that adds to the job queue?

I can't reproduce 5, the content of the section that's transcluded is from the stable version in my testing.

This ticket should address 1 to 4. The stable version would also be substituted. Included templates would have their stable version transcluded in both draft versions and stable versions, so there would be no difference to review (for 2, 4).

For the job queue, currently it's added at every edit. It would be feasible to push the recursive part of the links update when and only when the stable version changes, but this would require a new hook. Probably not essential IMO.