Extension talk:Approved Revs

"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 -- 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 .--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:


 * 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  that outputs the revision ID of the revision being viewed such that it can be used in other parser logic

For example:

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:  in Mediawiki:Common.js and get the information I needed into a wiki article (with a corresponding   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)

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
 * create page with ; it falls in category 1
 * edit to change contents to ; it falls in category 2
 * approve the first version of the page; it falls in category 1
 * edit to change contents to ; it falls in category 3.

When Semantic Mediawiki is installed, similar behaviour is seen with  and. I haven't extensively tested, but it might also appear when setting

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,  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, 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  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  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.

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;
 * 1) Enable Extension for Article And LL Approval

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:

//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;
 * 1) Enable Extension for Article And LL Approval


 * 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  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   which you change to   (to avoid a double bracket)

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

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  query's template result format. Something like this:

But  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

[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  does not exist in the class , even though it does exist for the class that replaces it ; but that class has only been available since MediaWiki 1.32.


 * Changing line  in the file   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)
 * 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! would it be possible to release 1.3.1 soon? --Planetenxin (talk) 07:28, 31 August 2020 (UTC)