Extension talk:Approved Revs/Archive 2018 to 2021

"Approval status" SMW property lags when using SESP

Please help me determine if the following behavior is a result of Semantic Extra Special Properties (SESP) [1] or Approved Revs (AR) [2].

I'm running:

• MediaWiki 1.30.0 (830bb58) 16:58, 8 December 2017
• Approved Revs 0.8.0 (28c6ce0) 17:46, 10 August 2018
• Semantic Extra Special Properties 2.1.0-alpha (6deea72) 03:01, 17 December 2018

The behavior is:

1. The "Approval status" property does not appear in the "Browse Properties" list of properties for new pages or any page that has no approval history.
2. The "Approval status" property does not appear in the "Browse Properties" list of properties for new pages with only the creation edit that have been approved.
3. The "Approval status" property only appears in the "Browse Properties" list of properties after an edit has been made after approving the page.
4. The "Approval status" property does not update to the current approval status until after an edit has been made after approving or disapproving the page.

In general. the "Approval status" of pages in SESP relies on subsequent edits to "push" the new approval status to SESP.

How can this be made to respond correctly? Thank you, User:revansx

[1] https://www.mediawiki.org/wiki/Extension:Approved_Revs

[2] https://www.mediawiki.org/wiki/Extension:Semantic_Extra_Special_Properties

Sounds like a SESP issue. Yaron Koren (talk) 03:36, 15 February 2019 (UTC)

Fatal error: Call to undefined method WikiPage::prepareTextForEdit()

Fatal error: Call to undefined method WikiPage::prepareTextForEdit() this is an error I am getting when editing the page as an user, but as an admin I can still see the user wanted to edit the page and can approve the page the user wanted to edit.

What line of code is that happening in, do you know? Also, what versions are you running of MediaWiki and Approved Revs? Yaron Koren (talk) 20:12, 28 March 2018 (UTC)

The latest version 0.7.3 but I just edit the codes with $editInfo = $page->prepareContentForEdit( new WikitextContent( $text )); in line 77 but now it auto approved I think because whenever the user edit the page it just saves automatically.

Oh, I see, you were using code from when 0.7.3 was released about a year ago, but then you just changed that line to match its current form. (I'm planning to release a new version very soon, by the way.) If you think there's a problem with approvals, let me know. Yaron Koren (talk) 17:14, 30 March 2018 (UTC)

Query Approval Data

I would like to know how to query approval data. For example, I would like to have a table display a list of pages (using #ask) and have it display the date of last approval.

I would also like to display the approval date within the body of the page similar to how you can display {{REVISIONDAY}}-{{REVISIONMONTH}}-{{REVISIONYEAR}} natively.

Is this possible?

No, there's no way to do either. Why do you want to display those? Yaron Koren (talk) 13:31, 1 May 2018 (UTC)

Our wiki needs to comply with some ISO requirements to show revision number and publication dates. If this could be done in a more automated fashion based on approved revisions, that would be fabulous.

Can't you just use REVISIONDAY, REVISIONMONTH, REVISIONYEAR and REVISIONID for those (assuming the ID is what you mean by the number)? Do those not show the correct data? Yaron Koren (talk) 13:15, 2 May 2018 (UTC)

You can try Extension:Semantic_Approved_Revs --Krabina (talk) 11:39, 21 August 2019 (UTC)

Update to 0.8 fails on Postgres

The update to 0.8 fails on a Postgres database because the new column approver_id is of type "int unsigned", which does not exist in Postgres. Obviously a fresh installation of 0.8 would fail for the same reason.

I removed the "unsigned" from the SQL script, and everything seems to be working now.--RV1971 (talk) 11:49, 9 May 2018 (UTC)

Sorry about that! I removed the "unsigned" from the two SQL files. Really I should have created a new patch for the change, but hopefully this is good enough. Yaron Koren (talk) 16:22, 9 May 2018 (UTC)

Remove namespaces from ApprovedRevsNamespaces

In my wiki, some of the namespaces included by default in ApprovedRevsNamespaces should not be subject to approval because edit on these pages is limited to a small group of people distinct from those writing the actual content. The main inconvenience of having unwanted namespaces here is that they pollute the "Unapproved pages" list on the special page, making it almost useless.

Is there any means (other than patching extension.json) to remove namespaces from this variable? If not, a good solution could be to re-implement ApprovedRevsNamespaces the same way as in $wgNamespacesWithSubpages.--RV1971 (talk) 12:25, 9 May 2018 (UTC)

Yes, you can remove namespaces. The easiest way is just to reset the value - if you want only the main and "User" namespaces to be handled, for instance, you could put the following after the inclusion of Approved Revs:

$egApprovedRevsNamespaces = array( NS_MAIN, NS_USER );

Yaron Koren (talk) 16:25, 9 May 2018 (UTC)

I'm afraid this does not work because settings in LocalSettings.php are merged with those in extension.json.--RV1971 (talk) 12:50, 11 May 2018 (UTC)

Problems after CSV_Import

When I use the CSV import of the Extension:Data_Transfer then all imported pages get "unapproved" even if the person importing has admin rights. This is a bug I guess.

Furthermore we have the problem that every entry shows up in the list 4 times: https://www.geschichtewiki.wien.gv.at/Spezial:Best%C3%A4tigte_Versionen even if the resulting pages show up as approved: https://www.geschichtewiki.wien.gv.at/Gedenktafel_Heinrich_Maier

Fortunately, the approveAllPages.php script fixes that, but it is not very convenient having to run this after every import... I am using the latest version of Approved Revs on MW 1.27 --Krabina (talk) 07:25, 6 August 2018 (UTC)

How to handle transclusions?

Hi, I'm switching from FlaggedRevs to AR, and I'm wondering how config of which version of a transcluded page to use works. For example we have a News page in Project ns where I want the most recent version to be transcluded, even if it's unapproved, but for templates I want a version to be approved before it's used elsewhere. Is this possible to config based on namespace or with a parser function? Thanks --RheingoldRiver (talk) 17:26, 27 August 2018 (UTC)

No - if some revision of a page is approved, that approved revision is what is used everywhere, including for transclusions. Yaron Koren (talk) 22:53, 27 August 2018 (UTC)

Approved pages show up as unapproved

Hi, I am currently facing some difficulties using your Approved Revs extension. After some changes in LocalSettings.php configuration, all approved pages show up unapproved although their log histories tell otherwise. The LocalSetting changes included reimporting the SemanticBundle extension and the configuration of extra namespaces via SemanticMediaWiki extension. I know that I could run the 'approveAllPages' maintenance script, but this creates unwanted localhost entries in the log history and erases the information about the original approver and approval date. Any ideas on my problem? Thanks in advance!

What version of Approved Revs and MediaWiki are you running? And what were the relevant LocalSettings.php changes? Yaron Koren (talk) 15:49, 26 September 2018 (UTC)

I'm running Approved Revs version 0.7 and MediaWiki version 1.24.1. The LocalSettings.php changes were: Deletion of SemanticBundleSettings.php and SemanticBundle.php import (require_once) and instead importing SemanticMediaWiki.settings.php with $smwgNamespaceIndex = 200. Some pages were moved (via moveBatch.php) from Mainspace to newly created namespace Property. After that there was no possibility to approve pages at all and I reinstalled SemanticBundleSettings.php and SemanticBundle.php. The functionality is now back but the pages are marked as unapproved.

You really shouldn't use Semantic Bundle any more - it's very old software. (Including a very old version of Approved Revs - 0.7 is from four years ago.) My guess is that what happened is that, as part of the uninstalling of Approved Revs, the database table it uses, called "approved_revs", got deleted - and then when you re-installed it, the DB table was re-added but now empty. Which means that all record of which pages are approved was lost - other than those log entries. You can check that by checking the approved_revs table, if you have access to the database. If that's the case, then you have to re-approve all those pages in one way or another - sorry. Yaron Koren (talk) 16:38, 26 September 2018 (UTC)

The database is not deleted, but the page_ids have been shifted somehow, which is why the scripts are not able to find the connection via id. I'll have to figure out how to match those ids again. Thanks for helping me!

Help making "wgRevisionId" a magic word

Hi,

I'm using Extension:Approved Revisions [1] and I have a need to be able to display the revision ID of the page revision currently being viewed. From the MW Manual page on Javascript [2] I see that the variable "wgRevisionId" contains this information and is exposed to mediawiki for use, but it is not clear to me how to do so. I would like to create a "magic word" [3] called Template:VIEWEDREVID that outputs the revision ID of the revision being viewed such that it can be used in other parser logic

For example:

{{#ifexpr:( {{VIEWEDREVID}} < {{APPROVEDREVID}} )
|if true
|if false
}}

Can someone please help me identify the way to make a magic word that contains the value of "wgRevisionId"?

Thank you! -Rich User:revansx

[1] https://www.mediawiki.org/wiki/Extension:Approved_Revs

[2] https://www.mediawiki.org/wiki/Manual:Interface/JavaScript

[3] https://www.mediawiki.org/wiki/Help:Magic_words

UPDATE/SOLVED - 2018-10-25 - HexMode explained to me that placing the revision id of the revision that the user is presently viewing (rather than simply the latest) would actually break the whole caching systems. He helped me realize that what I'm trying to do is best done in Mediawiki:Common.js. That said, I was able to write a simple JS line like this: document.getElementById('MyDiv001').innerHTML = mw.config.get('wgRevisionId'); in Mediawiki:Common.js and get the information I needed into a wiki article (with a corresponding <div id="MyDiv001"></div> in the page). Cool!

Is it possible to require approver to have edit right for the namespace in order to approve a page revision in that namespace?

I'm using multiple custom namespaces to organise pages for different projects. There will be different groups of people responsible for different projects. Currently, the permission 'approverevisions' grants an approver the ability to approve revisions in all namespace, regardless of whether the approver is a member of the group that has edit permission for the particular namespace that the page is in. Is there a way to control this? --theys (talk) 05:31, 6 November 2018 (UTC)

Use of deprecated method ArticleAfterFetchContentObject in MW 1.32.x

I get the following warning in debug mode in MW 1.32.x with this extension now.

Use of ArticleAfterFetchContentObject hook (used in ApprovedRevsHooks::showBlankIfUnapproved) was deprecated in MediaWiki 1.32.

Chiefgeek157 (talk) 03:19, 23 March 2019 (UTC)

This may be a challenge, because there's no obvious replacement for ArticleAfterFetchContentObject. The closest thing, I think, is ArticleRevisionViewCustom, which may or may not be helpful. It was only added in MW 1.32, though, and I'm not yet running that version, so this may take a while to fix. Hopefully they won't remove ArticleAfterFetchContentObject any time soon. Yaron Koren (talk) 17:35, 15 April 2019 (UTC)

Misleading Message

I’m just getting started with Approved Revs and loving it. One problem: when you are looking at an older revision, the first message below says you are looking at the latest revision. The next message indicates it’s not. This is confusing and potentially misleading.

This could lead the user to edit an out-of-date version. Although the user would get a warning that they were editing an out-of-date version, they could choose to ignore it because it conflicts with the erroneous information they have received, and they might choose to believe the erroneous information.

Is there any way to keep the conflicting messages from happening short of turning off the messages?

Thanks for a great extension, BTW.

---

This is the latest revision of this page; it has no approved revision.
Revision as of 11:07, 3 March 2019 by ‪Greg.Fuller‬ (talk | contribs) (diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

---

Gregoryfu (talk) 12:32, 22 April 2019 (UTC)

That's a bug - sorry about that. I guess I hadn't done much testing with the $egApprovedRevsShowNotApprovedMessage setting. I just checked in what I think is a fix for this. Yaron Koren (talk) 16:07, 23 April 2019 (UTC)

If a page has an approved revision and a user selects to edit with VE or source, the user is sent to edit the approved revision instead of the current revision

I'm experiencing this on:

• MW: 1.32.1 (8e4f995)
• SMW: 3.0.0
• AR: 1.0 (b2f77fb)
• VE: 0.1.0 (e82e120)

A user navigates to a page that has an approved revision and a link to view the current revision of the page. If the user selects to edit the page with Visual Editor or source, the page loads the approved revision instead of the current revision to edit. Before the edit links would always send the user to the current revision to edit. Is there a way to select a preference for which revision to edit?

Thanks in advance,

V brooks (talk) 17:15, 24 April 2019 (UTC)

That's very strange... it's definitely a bug, because the user should always be sent to edit the latest revision. Does the edit page that is linked to contain "oldid=" in the URL query string? Yaron Koren (talk) 18:21, 24 April 2019 (UTC)

I just came across this issue with a fresh install of MW 1.35.5, VE 0.1.2 (4e63a2f), AR 1.7.2:

If a page has an approved version, the edit link does contain oldid http://localhost:8080/index.php?title=Main_Page&oldid=1&veaction=edit. If the user now clicks edit, VE complains "Warning: You are editing an out-of-date revision of this page." At the same time, the Edit source link is http://localhost:8080/index.php?title=Main_Page&action=edit. The only setting is $egApprovedRevsAutomaticApprovals = false; Planetenxin (talk) 14:43, 10 February 2022 (UTC)

Data is being set from latest, unapproved page

Hi, I've come across an issue with Approved Revs 1.1 and 0.8, that wasn't present in 0.5.9.

Simplest way to reproduce on a new, otherwise clean wiki:

• load ApprovedRevs and set $egApprovedRevsAutomaticApprovals=false
• create page with [[category:1]]; it falls in category 1
• edit to change contents to [[category:2]]; it falls in category 2
• approve the first version of the page; it falls in category 1
• edit to change contents to [[category:3]]; it falls in category 3.

When Semantic Mediawiki is installed, similar behaviour is seen with {{#set:set=1}} and [[Semantic Link::1]]. I haven't extensively tested, but it might also appear when setting $egApprovedRevsBlankIfUnapproved = true;

Tested on multiple wikis, running MW 1.32.2 or MW 1.27.7

TIA for looking into this! --DWizzy (talk) 15:22, 19 June 2019 (UTC)

Yes, I am seeing that behavior too. Are you sure that this happens with AR 0.8 but not with AR 0.5.9, regardless of the MediaWiki version? If so, that's a still a big gap to try to narrow down, but it's a good start. Yaron Koren (talk) 17:19, 21 June 2019 (UTC)

Thanks for looking into it. The problem doesn't appear on MW 1.19 using AR 0.7.2 (the last version to support MW 1.19). I can't get my hands on a MW between 1.19 and MW 1.27 right now to test intermediate versions. MW 1.27 requires AR >= 0.8. --DWizzy (talk) 12:29, 25 June 2019 (UTC)

Any updates on this? YOUR1 (talk) 11:15, 8 July 2019 (UTC)

It appears this problem happens on all installs, $egApprovedRevsAutomaticApprovals=false doesn't play a role. Even when no further configuration is set; if any user changes an approved page, the latest unapproved version's values are used. This makes the impact of this issue quite high to me. --DWizzy (talk) 10:54, 11 July 2019 (UTC)

After some testing, some extensions use Revision::newFromTitle(), that function will always return the current revision of the page, even if its unapproved. I think the hook 'ArticlePageDataBefore' can fix this problem, the only problem is that I get segment faults when using it, so I can't debug anything.. I'm not sure if its only a problem with SMW, or just MediaWiki itself. YOUR1 (talk) 16:39, 11 July 2019 (UTC)

Cause known, working on a fix (Track ticket on Phabricator) --Remco de Boer 13:52, 12 July 2019 (UTC)

Follow up to question about Approved Revs and email notification

I'd like to follow up on the previously-raised question about email notifications and how they work with Approved Revs, here. I'm currently running MW 1.31.1 with AR 1.0-alpha (I haven't updated to the latest version 1.1 yet), with email notifications enabled. The current behaviour is that a user watching a page will get an email notification when the page is modified, whether or not the latest revision is approved. Is that the expected behaviour? At some point in the past, the behaviour was that the user watching the page will only get an email notification AFTER the revision has been approved. What ware the changes? I'd like to go back to the previous behaviour, primarily because most of the users of our wiki are straight up "consumers" of information. They couldn't care less about unapproved changes. I'd like to make it so that they would only receive email notification of the changes to a watched page AFTER the changes have been approved. --Tommy H. (talk) 00:03, 29 June 2019 (UTC)

Per-namespace authorization

The #approvable_by parser function allows one to specify which groups/users can approve changes to a particular page. Have you considered supporting this same concept at the namespace level?

e.g. have a config variable such as $egApprovedRevsEnabledNamespaces that maps a namespace to an array of groups/users who have permission to approve all pages in that namespace. Phantom Caleb (talk) 02:25, 18 August 2019 (UTC)

auto approves even user does not have permission to approve it

Hi,

I am using below settings, but it auto approves edited articles, even user does not have permission to approve the article.

Kindly check and update.

## Enable Extension for Article And LL Approval
wfLoadExtension("ApprovedRevs");
$wgGroupPermissions['*']['viewlinktolatest'] = false;
$wgGroupPermissions['sysop']['viewlinktolatest'] = true;
$wgGroupPermissions['App']['viewlinktolatest'] = true;
$wgGroupPermissions['*']['approverevisions'] = false;
$wgGroupPermissions['sysop']['approverevisions'] = true;
$wgGroupPermissions['App']['approverevisions'] = true;
$egApprovedRevsAutomaticApprovals = false;

Getting Approve Option and pages' latest revisions showing to every one

When i edited the article then latest content is showing to every one and Approve action is also showing same time.

Please update me if they is any changes in latest version

Sorry, I don't understand. Yaron Koren (talk) 13:54, 14 October 2019 (UTC)

@Yaron Thanks for your message,I have configured this extension for my WIKI, when any user edits the article (Article with namespace) it shows the latest content righter it must show the old one until i do not approve that article, same time Group admin have option to approve the article.

http://mywiki.com/index.php/LL:Testing

So you have one or more pages that have an approved revision that's not the latest, but the latest revision is the one that's shown? Yaron Koren (talk) 13:09, 16 October 2019 (UTC)

Yes, you are right,

Latest content showing without approval.

These are the setting what i am using:

## Enable Extension for Article And LL Approval
//require_once("$IP/extensions/ApprovedRevs/ApprovedRevs.php");
wfLoadExtension("ApprovedRevs");
$wgGroupPermissions['*']['viewlinktolatest'] = false;
$wgGroupPermissions['sysop']['viewlinktolatest'] = true;
$wgGroupPermissions['Lessons']['viewlinktolatest'] = true;
$wgGroupPermissions['*']['approverevisions'] = false;
$wgGroupPermissions['sysop']['approverevisions'] = true;
$wgGroupPermissions['Lessons']['approverevisions'] = true;
$wgGroupPermissions['*']['viewapprover'] = false;
$egApprovedRevsAutomaticApprovals = false;

Alright. Is the question above this one for the same wiki? If so, then it may explain this issue - pages' latest revisions get automatically approved on edit, which is why you always see the latest revision... Yaron Koren (talk) 13:01, 17 October 2019 (UTC)

1. same wiki 2. pages' latest revisions get automatically showing to every once. 3. Still Group have option to approve the page.

These are the my queries.

If i use $egApprovedRevsAutomaticApprovals = false; then no one can view the latest content until approved even approverevisions is too not able to see

I still don't understand. What do you mean by "no one can view the latest content" - anyone can see it by going to the history page and clicking on the latest revision, no? Yaron Koren (talk) 12:35, 18 October 2019 (UTC)

Special Page does not show all Pages if NS_FILE is among the enabled Namespaces ( Version 1.2 )

The special Page does not show all pages if the query is limited in number and the namespace for NS_FILE is enabled. Problem the generated database query retrieves Files and Pages from the database and then filters for Pages afterwards. Solution would be to drop the NS_FILE namespace in ApprovedRevs_body.php after Line 679.

$approvedRevsNamespaces = ApprovedRevs::getApprovableNamespaces();
		if (($key = array_search(NS_FILE, $approvedRevsNamespaces)) !== false) {
			unset($approvedRevsNamespaces[$key]);
		}

Auto approve api actions

Is it possible to auto approve actions made through the api?

Example: I've created an application that creates pages on my wiki using oauth and my admin account. But every page creations has to be manually marked as approved despite the edits coming from an admin account.

Likewise edits made by the PyWikiBot also have to be approved. I've added the approverevs right to the bot group. --Octfx (talk) 13:03, 28 November 2019 (UTC)

Have creators of pages own the page

Hi, thanks for the great extension. Is there a way to automatically grant users the ownership of their created pages? E.g. a normal user creates a new page, now only that user (and admins) have been automatically granted approved revs rights to their own page (not user page, normal page)? Thanks MavropaliasG (talk) 02:30, 2 December 2019 (UTC)

Yes - see here. Yaron Koren (talk) 02:40, 2 December 2019 (UTC)

Thank you Yaron, so by putting that command in the configuration of the extension, any page a user creates, anywhere in the mediawiki installation, will automatically be owned by them, and they will be the only ones to select which edits from other users they approve? Wow that's fantastic!

MavropaliasG (talk) 05:53, 2 December 2019 (UTC)

install fails on postgres

installing the current version fails on postgres:

Creating approved_revs_files table ...[126b9e4445d19d89f9aa9cbd] [no req]   Wikimedia\Rdbms\DBQueryError from line 1587 of ../Database.php: A database query error has occurred. Did you forget to run your application's  database schema updater after upgrading? 
Query: CREATE TABLE "approved_revs_files" (
 file_title varbinary(255) NOT NULL,
 approved_timestamp binary(14) NOT NULL,
 approved_sha1 varbinary(32) NOT NULL
 ) /*$wgDBTableOptions*/

Function: Wikimedia\Rdbms\Database::sourceFile( /extensions/ApprovedRevs/includes/../sql/ApprovedFiles.sql )
Error: 42704 ERROR:  type "varbinary" does not exist
LINE 2:  file_title varbinary(255) NOT NULL,
                   ^

replacing varbinary and binary with the equivalent BIT Postgres equivalents (*8 due to bit/byte) gets the update.php script working, but the Wiki then breaks with a generic RDBMS error.

What version of MediaWiki are you running? And what is the DB error? (You may need to add "$wgShowExceptionDetails = true;" to LocalSettings.php to see it.) Yaron Koren (talk) 14:53, 29 January 2020 (UTC)

MediaWiki 1.33.0 with SMW 3.1.3

DB Error is:

[040da32dbe23d9735098235a] /dragoneye/atlas/Main_Page Wikimedia\Rdbms\DBQueryError from line 1587 of /var/www/dragoneye/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT approved_timestamp,approved_sha1 FROM "approved_revs_files" WHERE file_title = 'PoliticalMap.jpg' LIMIT 1 Function: Wikimedia\Rdbms\Database::selectRow Error: 22P02 ERROR: "P" is not a valid binary digit LINE 1: ... FROM "approved_revs_files" WHERE file_title = 'Political...

Needless to say, I **did** run update.php - I figure the replacement I did didn't exactly work out.

Second attempt using "bytea" instead of BIT. This gets update.php and the main pages working, and I see the "approve" link in the page history, but when I access Special:ApprovedRevs I get:

Special:ApprovedRevs Wikimedia\Rdbms\DBQueryError from line 1587 of /var/www/dragoneye/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT DISTINCT p.page_id AS id,ar.rev_id AS rev_id,p.page_latest AS latest_id FROM "approved_revs" "ar" JOIN "page" "p" ON ((ar.page_id=p.page_id)) LEFT OUTER JOIN "page_props" "pp" ON ((ar.page_id=pp_page)) WHERE (p.page_latest != ar.rev_id AND ( ( pp_propname = 'approvedrevs' AND pp_value = 'y' OR pp_propname = 'approvedrevs-approver-users' OR pp_propname = 'approvedrevs-approver-groups' ) OR ( p.page_namespace IN ( 0,2,4,10,12 ) ) )) ORDER BY p.page_namespace,p.page_title LIMIT 51 OFFSET 0 Function: SpecialApprovedRevsPage::reallyDoQuery Error: 42P10 ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list LINE 1: ....page_namespace IN ( 0,2,4,10,12 ) ) )) ORDER BY p.page_nam...

Approve link on list of pages whose approved revision is not their latest

Special:ApproveRevs shows a link to approve a page directly from the special page only the list of pages with unapproved versions. (&show=unapproved)

I wanted to have this link also on the list of pages whose approved revision is not their latest. Currently, there is only the link to the diff of the new edit to the revised version. It makes sense to provide this, because changes should be reviewed before approved. However, there are circumstances, where a lot of edits (e. g. of a trustworthy user that does not (yet) have autoapproved privileges) are to be approved. It is cumbersome to click on each entry twice: first to come to the diff and then approve it there.

So I did this code change which shows the approval link also on the list of pages whose approved revision is not their latest:

                        global $egApprovedRevsShowApproveLatest;
                        if ( $egApprovedRevsShowApproveLatest &&
                                ApprovedRevs::checkPermission( $user, $title, 'approverevisions' ) ) {
                                $diffLink .= ') (' . Xml::element( 'a',
                                        array( 'href' => $title->getLocalUrl(
                                                array(
                                                        'action' => 'approve',
                                                        'oldid' => $result->latest_id
                                                )
                                        ) ),
                                        wfMessage( 'approvedrevs-approvelatest' )->text()
                                ) . ')';
                        }

You insert this code in row 232 of includes/SpecialApprovedRevsPage.php, right before the return "$pageLink ($diffLink)";.

This is somewhat a hack and can probably done nicer, but it works in case anybody else needs that.

update: in a more recent version, the file is in the subfolder "includes special" and it is line 262, not 232. But this still works. Just tested again, this still works in version 1.7.3 where it is in line 266.

Auto-approve related pages

I'm starting this topic to discuss possible solutions to auto-approve related pages (related through a semantic property)

Scenario: Let's say we have a "Workflow" page and several "Task" pages detailing the workflow. As a user, when I approve the workflow (on the workflow page), I'd like to auto-approve related pages.

I was thinking of a parser function that is part of an #ask query's template result format. Something like this:

{{#approve:{{{Related Page|}}}}}

But #approve should only be triggered when running the approve action...

Any thoughts on this? Other approaches?

--Planetenxin (talk) 11:17, 10 June 2020 (UTC)

Well, #approve is a bit too general a name for this kind of function - #chain_approval instead, maybe? But I'm wondering: how can you be sure, without looking at a page, that it should be approved? Of course, if you're looking at its data in a query, then you can determine that the data looks fine, but what if someone went into that page and changed the free text? You would (I assume) have no way of knowing. Yaron Koren (talk) 13:35, 10 June 2020 (UTC)

Many thanks for your prompt feedback, Yaron. Of course, someone who is doing such an approve should have checked the pages before approval. This is more an organizational issue. I rather wondered if it is technically possible to combine such a parser function with the approve action, i.e. to update the related pages only in the "approve" case, not during page view etc. --Planetenxin (talk) 13:44, 10 June 2020 (UTC)

Oh, okay. Yes, I'm guessing that it's technically possible. Whether it's useful is another question, of course... Yaron Koren (talk) 13:54, 10 June 2020 (UTC)

Error saving a page if $egApprovedRevsAutomaticApprovals=false; (MW 1.31)

• MW 1.31
• AR 1.3
• $egApprovedRevsAutomaticApprovals = false;

[6d179d1599c70505b959b54e] /wiki01/index.php?title=Test&action=submit Error from line 113 of /var/www/wikis/wiki01/extensions/ApprovedRevs/includes/ApprovedRevs.php: Undefined class constant 'MAIN'

-- This contribution was posted by 212.77.177.35

This seems to be an issue with the Approved Revs extension. The constant MAIN does not exist in the class MediaWiki\Storage\SlotRecord, even though it does exist for the class that replaces it (MediaWiki\Revision\SlotRecord); but that class has only been available since MediaWiki 1.32.

Changing line 114 in the file extensions/ApprovedRevs/includes/ApprovedRevs.php from

$role = MediaWiki\Storage\SlotRecord::MAIN

to

$role = "main";

should solve the issue. Xxmarijnw (talk) 14:02, 24 August 2020 (UTC)

Where was the "MAIN" constant defined in MW 1.31? Or was there no "MAIN" constant at all, and the string "main" is what should be used? Yaron Koren (talk) 14:21, 24 August 2020 (UTC)

@Yaron Koren: I am not 100% sure, but I don't think a MAIN constant was defined in MW1.31. Xxmarijnw (talk) 18:43, 25 August 2020 (UTC)

Okay, thanks. I just changed the code to use the string "main" for MW 1.31, so now Approved Revs should work again with MW 1.31. Yaron Koren (talk) 20:23, 25 August 2020 (UTC)

I can confirm that the fix provided by Xxmarijnw is fixing the issue. Many thanks for this! @Yaron Koren: would it be possible to release 1.3.1 soon? --Planetenxin (talk) 07:28, 31 August 2020 (UTC)

Is it possible to exclude certain categories from the plugin?

We have a certain Category with 3 subcategories that are listed by the Extension "Intersection" (DynamicPageList). Its because with that we track errors in our everyday processes. An these errors have to be discussed by the team. And is going to be closed then. So the error is put from [Errors:open] to [Errors:workinprogress] to [Errors:closed]. If one of these Errors (represented by a page) is not appoved it does not show in the corresponding list, because the "official" page is still with the old content, which contains the old Category. So id like to exclude this categories. But i dont know how... I tried something like: #$egApprovedRevsEnabledNamespaces[NS_CATEGORY:Errors:open] = false; but I could not find the right syntax..Can you please give me an advice? Thanks

I don't think there's a way to do that, unfortunately. Yaron Koren (talk) 18:22, 10 November 2020 (UTC)

Parser function not working

When I add the below text (for example) to a page

{{#approvable_by: users = Alice Jones | groups = bureaucrat,sysop }}

It is not being parsed and is visible on the page.

I am running MW 1.35.0, ApprovedRevs 1.3.1 and ParserFunctions 1.6.0, I can see approvable_by listed as a parser function hook on Special:Version

Any advice how to debug/fix?

Thanks!

Issue with file deleting and file approvals

The is a small issue with file approvals. It is even visible in your screenshot:

As the file in the middle is the approved one, it should be possible to delete the most recent one (because it is wrong or inapproproate or somehing). But the link left of the image preview shows only "delete all", because it is the most "current" file. So how can you delete the most recent file version (the unapproved one) without deleting all files? --Krabina (talk) 14:44, 14 January 2021 (UTC)

That's interesting - I didn't notice that before. It seems like a MediaWiki design decision to not let users delete the latest version of a file - I don't know if Approved Revs can (or should) change it. If you really want to delete the latest version, I guess... upload a new version? Yaron Koren (talk) 15:29, 14 January 2021 (UTC)

Bug with approvals

i receive an error when i try to approve edits. It's a new mw installation. On clicking "Approve All", i'm redirected to page: http://gunretort.xyz/index.php?title=Special:Moderation&modaction=approveall&modid=2&token=5eb8f47cacfa18c5916e2c94be9575566017c816%2B%5C

On clicking "Approve" i get: Warning: in_array() expects parameter 2 to be array, int given in /home/gunsywtx/public_html/extensions/ApprovedRevs/includes/ApprovedRevs.php on line 364

Update: Solved. Needed square brackets on config: $egApprovedRevsSelfOwnedNamespaces[] = NS_USER ;

Johnywhy (talk) 17:41, 1 February 2021 (UTC)

Approval failed

Change made by another extension can't get approved.

1. (diff) . . bN Template:Extension DPL 04:07 . . +253‎ . . 127.0.0.1^[?] (Template:Extension DPL) [Approve Approve all . . Reject Reject all] . . [Mark as spammer]

On click "Approve", i get: Your edit was ignored because no change was made to the text.

On click "Approve all", i get: Approved 0 edits. Failed to approve 1 edit: edit conflicts, etc.

The changed page says: This page was automatically created. It serves as an anchor page for all invocations of Extension:DynamicPageList (DPL).

Johnywhy (talk) 18:44, 1 February 2021 (UTC)

I don't know where that interface is coming from, but it's not from the Approved Revs extension. FlaggedRevs, maybe? Yaron Koren (talk) 20:29, 1 February 2021 (UTC)

My mistake -- it's the Moderation extension. Johnywhy (talk) 20:20, 2 February 2021 (UTC)

Adjusting the ApprovedRevs Messages

Hello,

Thank you for making this extension available for us, it is really helpful.

I have been trying to adjust the layout of the ApprovedRevs site status, to increase its visibility. For example I want all messages to have a larger font-size and depending on the message to be displayed with a different font-color. I have tried achieving this through the special page "Mediawiki:Common.css" and the "ApprovedRevs.css" file fromthe extension folder.

Unfortunately this has only worked "approvedAndLatestMsg" so far. If I add css code for the other messages in the "ApprovedRevs.css" there is no effect on my wikipages. As a workaround I have added css descriptions to the "contentSub" class, which however also alters other messages.

I think the issue is that the "approvedAndLatestMsg" seems to be its own css class whereas the other messages are somehow only subclasses of the "contentSub" class?

How can I assign change the Layout of the Messages displayed by ApprovedRevs only? Is this even possible?

Screenshots for clarification:

Screenshot 1 - Altered "approvedAndLatestMsg", with font-size: 16px and color: green.

Screenshot 2 - Message how I would like it displayed, but as shown with the inspector only available as part of "contentSub"

Screenshot 3 - The issue if I alter the css for "contentSub", some other messages also gain some more visibility. Example given: the info that this page is a redirected page.

I would really appreciate some help and am definetly willing to write a section for the documentation if we find a suitable fix for this, so other can customize ApprovedRevs.

Thank you

Edit: I found a workaround to achieve my goal. In the end I adjusted the CSS classes for the redirect messages as well, to have a different color and a smaller font-size.

APPROVEDTIMESTAMP meaning

Hi, thanks for adding APPROVEDTIMESTAMP etc.

I understand that this field is the "timestamp when the page was approved".

I was hoping that this field would show the "timestamp of the edit of the approved revision of the page".

Ultimately, what I'm trying to do (like some others I think) is to be able to generate dynamically within the page some data about if you are looking at the approved version of the page, or not. Similar to the text at the top of the field, but to have control over this in the page.

Something like this (but not APPROVALTIMESTAMP): {{#ifexpr: {{APPROVALTIMESTAMP}} < {{REVISIONTIMESTAMP}} | There are new unapproved changes | This page is approved and there are no new changes yet to approve }}

If that's all you need this value for, then you don't really need a timestamp, just a boolean, like "ISLATESTAPPROVED" - no? Yaron Koren (talk) 16:46, 28 April 2021 (UTC)

The timestamp was just a means to an end, a boolean would be better, yes.

The functionality in the existing messages is the right sort of thing:

• "approvedrevs-notlatest": "This is the approved revision of this page; it is not the most recent.",
• "approvedrevs-approvedandlatest": "This is the approved revision of this page, as well as being the most recent.",
• There are multiple other messages under the category: "This is not an approved version".

I think that there are two boolean flags that would be useful:

• ISAPPROVED: "This revision of the page is the current approved version", and
• Either:
  • UNAPPROVEDREVISIONS: "There are revisions that are newer than the approved version", or
  • THISISLATESTREVISION: "This page is the latest revision".

From those flags, I think we can generate the relevant status messages on the page directly.

Ianb1469 (talk) 10:51, 30 April 2021 (UTC)

Unapproved pages cannot be approved

Minor bug report?

If $egApprovedRevsBlankIfUnapproved = true; and you unapprove a page, then all "approve" links in the revision history do not appear and it's not possible to approve any other revision of the page until the page is edited.

It seems to be OK if $egApprovedRevsBlankIfUnapproved is false.

Ianb1469 (talk) 11:52, 30 April 2021 (UTC)

That sounds like a major bug! I can't reproduce this problem, though. What versions of MediaWiki and Approved Revs are you running? Yaron Koren (talk) 13:24, 30 April 2021 (UTC)

Here is what I'm running:

• MediaWiki 1.35.2
• ApprovedRevs 1.4 (9cf250d) 08:30, 22 April 2021

Here are the config lines:

wfLoadExtension( 'ApprovedRevs' );
$egApprovedRevsAutomaticApprovals = false;
$wgGroupPermissions['*']['viewlinktolatest'] = true;
$wgGroupPermissions['*']['approverevisions'] = true;
$wgGroupPermissions['*']['viewapproverviewapprover'] = true;
$egApprovedRevsBlankIfUnapproved = true;
$egApprovedRevsEnabledNamespaces[NS_MAIN] = false;
$egApprovedRevsEnabledNamespaces[NS_USER] = false;
$egApprovedRevsEnabledNamespaces[NS_FILE] = false;
$egApprovedRevsEnabledNamespaces[NS_HELP] = false;
$egApprovedRevsEnabledNamespaces[NS_PROJECT] = false;
$egApprovedRevsEnabledNamespaces[NS_TEMPLATE] = false;

The page is marked with __APPROVEDREVS__. Ianb1469 (talk) 14:01, 1 May 2021 (UTC)

I can no longer reproduce it, maybe it was something else. I wonder if it might have been a caching issue for a template. I don't know. Anyway, seems fine now. Ianb1469 (talk) 09:59, 21 June 2021 (UTC)

That's great to hear! Yaron Koren (talk) 02:06, 25 June 2021 (UTC)

Linking Revisions of Files and Wiki Pages they are embedded in

Hello,

Is it possible to have the revision of Files and the pages they are embedded in linked?

I use embedded draw.io diagrams Extension:DrawioEditor to display process flows in a wiki. Changes made to the process page require Approval by a certain user group.

The problem is that changes made to the diagram do not require an Approval. So a user could change the process flow, without having to have these changes to be approved. Also when approving the process page an Approver can not see if the embedded file (e.g. the process flow) has been altered and requires Approval.

What I would like to have is ideally that changes to a file that is embedded on another page are treated like changes to the page itself, so the page requires a fresh Approval in order to be displayed for normal users. Alternatively maybe a way to display to Approvers if the embedded file has been changed and requires Approval. So basically a linked Page history between the file page and the process page, so if a change is made to the file the process page will require Approval.

Is there a functionality in ApprovedRevs that provides what I'm looking for? Is this even possible in the current Mediawiki environment? Did any of you maybe have the same issue and found a solution?

Is it maybe possible to develop this as a feature for the ApprovedRevs Extension? Funding would be available depending on the required amount.

Let me see if I understand this correctly: you have a page P, which displays an image file, F. (It sounds like the issue is the same whether or not the file was created with draw.io.) Every time a change is made to F, you want P to require approval to show the new version of F. But what is displayed on P before the approval happens - the older version of F? The previously-approved version of F? No image at all? Also, why not just require approval for changes to the file? Yaron Koren (talk) 14:18, 29 September 2021 (UTC)

Hello Yaron, sorry I didn't get a notification when you posted your answer. You are absolutely right, the issue does not depend on the creation of the file with draw.io, but draw.io makes the issue more prevalent. I am using the setting: $egApprovedRevsFileAutomaticApprovals = false; and $egApprovedRevsBlankIfUnapproved = true;, however this does not affect the page P when F has been edited. And since with draw.io you can edit F while browsing P, it will easily happen that changes are made to F without being approved. When a normals user who does not have deeper knowledge of the workflow now accesses P, he or she will not be aware that the version of F being displayed is not approved.

In an ideal world what I would like to be displayed on P is a warning that the displayed version of the embedded file is not approved. What would actually work as well is no image being displayed at all on P, therefore signalling that an approval of the embedded file is needed. AID-PMBD (talk) 13:56, 13 October 2021 (UTC)

There's a relatively new setting, $egApprovedRevsBlankFileIfUnapproved, which may be helpful here - it's like $egApprovedRevsBlankIfUnapproved, but for files. I realized that I accidentally left this variable out of the documentation, so I just added it in now. Yaron Koren (talk) 02:31, 14 October 2021 (UTC)

That's exactly what I was looking for, thank you. You are always being super helpful! AID-PMBD (talk) 09:08, 14 October 2021 (UTC)

The setting works great for regularly embedded files, however after some testing it seems that the setting does not work when diagrams are inserted into a wiki page by the draw.io parser function. Regularly inserted files are displayed as blank, however when implementing a diagramm by using {{#drawio:NAMEOFTHEDIAGRAM}} the diagram is fully displayed. I guess this is probably connected to the parser function offering inpage editing of the diagrams. AID-PMBD (talk) 15:58, 14 October 2021 (UTC)

Oh, I didn't realize that DrawioEditor has its own parser function to display diagrams. That's a problem, then - it could be that the only solution to this is for someone to modify DrawioEditor to make use of Approved Revs settings. Yaron Koren (talk) 15:13, 14 October 2021 (UTC)

Approval status changes when moving a page

When I move a page that is approved, it then shows in the list of pages that need approval. I guess this is not intended behaviour, but a bug. The user that moved the page had autoapproval rights. --Krabina (talk) 09:45, 15 October 2021 (UTC)

Error on version 1.7

Hello, Just upgraded to version 1.7 (MW 1.34) and now im unable to approve pages.

Error:

[1f110d112675b770780c5bab] /mediawiki/index.php?title=Test55&action=approve&oldid=3989 Error from line 1125 of /var/www/html/mediawiki/includes/Linker.php: Call to protected method MediaWiki\Revision\RevisionStoreRecord::userCan() from context 'Linker'

Backtrace:

1. 0 /var/www/html/mediawiki/extensions/ApprovedRevs/includes/ApprovedRevsHooks.php(562): Linker::revUserTools(MediaWiki\Revision\RevisionStoreRecord, boolean)
2. 1 /var/www/html/mediawiki/extensions/ApprovedRevs/includes/ApprovedRevsHooks.php(709): ApprovedRevsHooks::setOldSubtitle(Article, integer)
3. 2 /var/www/html/mediawiki/includes/Hooks.php(174): ApprovedRevsHooks::setSubtitle(Article, integer)
4. 3 /var/www/html/mediawiki/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)
5. 4 /var/www/html/mediawiki/includes/page/Article.php(1554): Hooks::run(string, array)
6. 5 /var/www/html/mediawiki/includes/page/Article.php(733): Article->setOldSubtitle(integer)
7. 6 /var/www/html/mediawiki/extensions/ApprovedRevs/includes/ARApproveAction.php(60): Article->view()
8. 7 /var/www/html/mediawiki/includes/MediaWiki.php(511): ARApproveAction->show()
9. 8 /var/www/html/mediawiki/includes/MediaWiki.php(302): MediaWiki->performAction(Article, Title)
10. 9 /var/www/html/mediawiki/includes/MediaWiki.php(900): MediaWiki->performRequest()
11. 10 /var/www/html/mediawiki/includes/MediaWiki.php(527): MediaWiki->main()
12. 11 /var/www/html/mediawiki/index.php(44): MediaWiki->run()
13. 12 {main}

Any ideas?

Thanks

Sorry about that - it looks like I accidentally broke support for MediaWiki versions below 1.35 a few months ago. I just checked in a fix for this; if you get the very latest code (via Git), hopefully it will work again. Yaron Koren (talk) 15:01, 18 November 2021 (UTC)

Thank you. Tried your fix and now there is another error:

[2afaefbd436efe347fd56272] /mediawiki/index.php?title=Test103&action=approve&oldid=4000 TypeError from line 1577 of /var/www/html/mediawiki/includes/Linker.php: Argument 1 passed to Linker::revComment() must be an instance of Revision, instance of MediaWiki\Revision\RevisionStoreRecord given, called in /var/www/html/mediawiki/extensions/ApprovedRevs/includes/ApprovedRevsHooks.php on line 584

Backtrace:

1. 0 /var/www/html/mediawiki/extensions/ApprovedRevs/includes/ApprovedRevsHooks.php(584): Linker::revComment(MediaWiki\Revision\RevisionStoreRecord, boolean, boolean)
2. 1 /var/www/html/mediawiki/extensions/ApprovedRevs/includes/ApprovedRevsHooks.php(718): ApprovedRevsHooks::setOldSubtitle(Article, integer)
3. 2 /var/www/html/mediawiki/includes/Hooks.php(174): ApprovedRevsHooks::setSubtitle(Article, integer)
4. 3 /var/www/html/mediawiki/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)
5. 4 /var/www/html/mediawiki/includes/page/Article.php(1554): Hooks::run(string, array)
6. 5 /var/www/html/mediawiki/includes/page/Article.php(733): Article->setOldSubtitle(integer)
7. 6 /var/www/html/mediawiki/extensions/ApprovedRevs/includes/ARApproveAction.php(60): Article->view()
8. 7 /var/www/html/mediawiki/includes/MediaWiki.php(511): ARApproveAction->show()
9. 8 /var/www/html/mediawiki/includes/MediaWiki.php(302): MediaWiki->performAction(Article, Title)
10. 9 /var/www/html/mediawiki/includes/MediaWiki.php(900): MediaWiki->performRequest()
11. 10 /var/www/html/mediawiki/includes/MediaWiki.php(527): MediaWiki->main()
12. 11 /var/www/html/mediawiki/index.php(44): MediaWiki->run()
13. 12 {main}

Sorry - clearly there were further problems. I just checked in another fix; hopefully now it works better... Yaron Koren (talk) 16:13, 19 November 2021 (UTC)

Works now, thank you!