Extension talk:Approved Revs

Autoapprove changes to templates or files
Hi, I really don't want to re-approve every page that has a template, when I change the template. Is there a way to disable this requirement or auto approve in these cases? Heinrich krebs (talk) 14:46, 22 January 2014 (UTC)


 * Hi - I don't know what you mean by that - what happens when you change a template used by a page with an approved revision? Yaron Koren (talk) 14:49, 22 January 2014 (UTC)
 * I get a message, stating that a template of file was changed and that I should approve said change. It appears on every page in the "article" namespace, that has the changed template in use. Heinrich krebs (talk) 06:29, 12 May 2014 (UTC)


 * Could it be that you're actually using the FlaggedRevs extension? Yaron Koren (talk) 12:18, 12 May 2014 (UTC)

Using this extension for draft revisions
I'm not sure if this is feasible, but here goes anyway. I basically want a light-weight extension that allows an editor who needs it to save one or multiple draft versions of a page and later to submit the version that's fit for public view. This is arguably the same thing as marking a page as both approvable and unapproved, which is why I'm considering the Approved Revs extension, but I would like to simplify the process. I was wondering if the following approach is feasible: Is this safe to do? Or does the latest unapproved revision need to be 'approved' before removing __APPROVEDREVS__ ? Note that it is meant to bypass explicit approval in favour of making something no longer approvable, killing two birds with one stone. My biggest concern about this is that switching __APPROVEDREVS__ on and off again at irregular intervals may lead to unexpected behaviour. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 12:43, 16 February 2014 (UTC)
 * make pages approvable only by having __APPROVEDREVS__ as an option.
 * The option would be available as a checkbox in a form (Extension:Semantic Forms) so that it can be switched on and off.
 * When a couple of drafts later, the new version of the page is good to 'go live', all you need to do is to uncheck the checkbox and save the page.


 * What's the need for all this extra interface stuff - why not just use the standard Approved Revs approval process? Yaron Koren (talk) 14:47, 16 February 2014 (UTC)


 * Quite simply because it seems more wearisome having to approve every latest revision. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 09:13, 17 February 2014 (UTC)


 * Ah, I think I get it. Is the idea that "blank if unapproved" would be set to true? That might have been the missing piece. If so, you're essentially talking about using Approved Revs as a page-blanking system - a directive like __DISPLAYBLANKPAGE__ might be ideal for your case. :) Perhaps actually creating an extension that does that is the way to go, as silly as it sounds? It would be less overhead, and not have the potential pitfalls of Approved Revs. Thinking about it now, there actually may be a lot of use for such an extension, especially when combined with Semantic Forms. Yaron Koren (talk) 14:56, 17 February 2014 (UTC)


 * Well, blanking the entire page seems a little extreme. The latest revision before the page is made approvable should be fine, if at all possible. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 09:09, 19 February 2014 (UTC)


 * Okay, I misunderstood the question, then. What's superior (or less wearisome) about clicking on "Edit with form", checking the checkbox, and then saving the page, vs. going to the history page and clicking "approve" on the top line? Yaron Koren (talk) 13:42, 19 February 2014 (UTC)


 * That's not a fair comparison : ) Not all pages will necessarily have to go through the approval process and those that do will need to only for the time concerned. During those intervals of revision, every page edit would be a matter of "open form and edit, then add, keep or remove the magic word (whether or not this comes with a checkbox), and save the page". Let me narrow down the question to this: (1) can the magic word ( __APPROVEDREVS__ ) be removed from the page when it is no longer needed (or is it necessary to approve the page first); (2) can the same process, i.e. adding and removing the magic word, be applied more than once on the same page? Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 14:58, 19 February 2014 (UTC)


 * Alright - I still don't understand, but since that's all you want to know, I guess it's not relevant anyway. Unfortunately, my answer is: I don't know. :) Yaron Koren (talk) 15:32, 19 February 2014 (UTC)

BlankIfUnapproved only for some groups
Is it possible to use "BlankIfUnapproved" only for special groups? For example a Administrator see the unapproved page, but a normal User see blank?


 * No, it's not possible. I'm not sure if that would be a good idea: it would mean that admins might not be aware of what regular users are seeing. Yaron Koren (talk) 16:46, 6 March 2014 (UTC)

Thank you for the fast answer! I think it would be very helpful. If an author write an unapproved articel and want to change something later, he has to click on the link or history tab. And without the blank-function I have no possibility to see on the first look, if a page is approved or not. Or is there an option?


 * Yes, it's more work for the admin - but as I said, maybe that's good, in that it's a constant reminder that a revision on the page needs to be approved. As for seeing whether a page has been approved, if "blank if unapproved" is turned off, there will be a little message at the top of the page indicating that - see here, for example. Yaron Koren (talk) 15:12, 7 March 2014 (UTC)

Sectioneditlinks gone
Our intranet wiki relies heavily on section edit links being available. These links are shown only on the current revision, as calculated on line 560 of article.php: elseif ( !$this->isCurrent || !$this->getTitle->quickUserCan( 'edit', $user ) ) { $parserOptions->setEditSection( false ); } An article is never current when Approved Revs loads the approved revision because of showApprovedRevision (&$title, &$article). This function replaces the current article object with a new one that has a revisionID which causes article.php to view the article as !current.

I've been trying to find a workaround. Initially, I added $article->mOldId=0 to function showApprovedRevision. This worked (edit links visible) but broke the function setSubtitle...The custom Approved Revs subtitles don't get displayed.


 * This works fine for me - if the latest revision is approved, all the section edit links appear. What version of Approved Revs and MediaWiki are you using? Yaron Koren (talk) 14:25, 23 March 2014 (UTC)


 * We're using MediaWiki 1.19.7 and Approved Revs version 0.6. We're also using Vector skin.


 * Alright - upgrading your version of Approved Revs might help. Yaron Koren (talk) 16:04, 26 March 2014 (UTC)

Can't suppress 'View the most recent revision' link
MW 1.22.5

Extension v. REL1_22

My LocalSettings:

require_once( "$IP/extensions/ApprovedRevs/ApprovedRevs.php" ); $egApprovedRevsAutomaticApprovals = false; $egApprovedRevsShowNotApprovedMessage = false; $egApprovedRevsShowApproveLatest = true; $egApprovedRevsSelfOwnedNamespaces[] = array(NS_USER ); $egApprovedRevsBlankIfUnapproved = true; $wgGroupPermissions['*']['viewlinktolatest'] = false; $wgGroupPermissions['sysop']['viewlinktolatest'] = true;
 * 1) Extension: ApprovedRevs

As a test, I created a new page and did not approve it. Then I logged in as a regular User and see the message at the top of the page "No revision has been approved for this page. View the most recent revision."

I require new pages with no approved revisions to be blank and for normal Users NOT to see the link to the most recent revision. Shouldn't the $wgGroupPermissions['*']['viewlinktolatest'] = false; setting achieve this?

Am I missing a Permissions setting, or is this a bug?

Thanks Bill


 * That is indeed a bug - I just fixed it in Git. Thanks for pointing out the problem. Yaron Koren (talk) 20:49, 28 April 2014 (UTC)

make ApprovedRevsSelfOwned assignable to individual user groups
Can you make the ability to allow users to own their own pages assignable to user groups? In my application, I have created a user group 'writer'. I want that group to be able to own their own pages for approval purposes. I want to give the group 'user' permission to create a page, but for that page to be blank until approved.

Or is there a way to do that that I have not seen?


 * Unfortunately, no - there's no way to do user-group-based permissioning. There are general long-term plans to add such a thing, in addition to category-based permissions. Yaron Koren (talk) 21:07, 7 May 2014 (UTC)

Thanks Yaron. Those would be very useful capabilities. Regards, Jeff


 * Jeff,


 * As Yaron mentioned there are plans to add this functionality. I have modified the extension to provided the capabilities I believe you are interested in, but Yaron and I simply have not had the time to work together to merge in the changes. My fork of the extension can be found at https://github.com/jamesmontalvo3/MediaWiki-ApprovedRevs


 * My organization has been using this fork for about six months and it is working well for us. We have a wiki with about 2500 pages, 40 active contributors and 2000 page views a day, so it has gotten decent field testing. The modified extension allows specifying different approvers based on namespace and category. It even allows you to say, for example, that all pages of category "Story" will be approvable by whoever is set as "Author" of the page using semantic properties. So if we set this page to and then added Author::Jamesmontalvo3 and Author::Jeffatcw then you and I would be able to approve this page, but Yaron would not (Sorry, Yaron :-) ). This of course requires the Semantic MediaWiki extension installed to support properties.


 * Yaron, we should setup a time to discuss the merge.


 * --Jamesmontalvo3 (talk) 15:21, 8 May 2014 (UTC)


 * Any time is good with me! Yaron Koren (talk) 16:28, 8 May 2014 (UTC)