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)


 * Oh, Yes I do. Sorry. Heinrich krebs (talk) 14:57, 14 August 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)

James (and Yaron),

Thanks for this. I am going to give it another field test for you. My wiki is still in development so it will be a small test. I'll let you know how it goes. I do have Semantic Mediawiki installed.

Regards, Jeff Update from Jeff 5/21/2014:

When we looked it appeared that James' fork uses an older version of the extension that does not have some bug fixes. We have elected to wait until you are able to merge.

Possible performance problem
See Thread:Project:Support desk/Some pages taking 7 - 15 seconds to load --Ciencia Al Poder (talk) 09:30, 27 May 2014 (UTC)

CategoryPermissions deactivates ApprovedRevs?
My plan was to use ApprovedRevs only in a certain namespace/category and also only permit sysops to approve and edit articles in that namespace/category. I figured using both ApprovedRevs and CategoryPermissions would be the way to go. Unfortunately when I activate CategoryPermissions in my LocalSettings.php I can't approve or disapprove any more articles. Still, the old approved versions are being showed as default and I can see the star in the history. Any suggestions how to fix this?

Approved revisions shown twice on "Special:ApprovedRevs"
Heiya,

I noticed that the special page lists approved pages/versions twice like e.g. The respective wiki is using Approved Revs 0.7 on MW 1.23.1 with PHP 5.4 Probably there is something in the water...
 * 1) "Main Page" (Version 2)
 * 2) "Main Page" (Version 2)

Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:04, 21 July 2014 (UTC)


 * Is it on "Unapproved Pages" list only, or have you noticed it on others? I believe this patch is the issue. It has been reverted in an upcoming release of Approved Revs. --Jamesmontalvo3 (talk) 20:32, 21 July 2014 (UTC)


 * Oops, I was not very clear about this. It is only happening in the list of pages that have an approved revision. The list with all pages whose approved revision is not their latest revision, and the list of all pages that do not have an approved revision are ok. Let's see what happens in the next release. Thank you for your feedback. --&#91;&#91;kgh&#93;&#93; (talk) 07:28, 22 July 2014 (UTC)


 * Well, just found out that this duplication causes a serious issue in combination with the Semantic Forms extension. Due to the duplication the pages now believe that two forms are defined for it thus making it uneditable. Just had a look at the repo. Apart from translation updates, version 0.7 is the latest version. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:42, 24 July 2014 (UTC) PS Hmm, this is pretty weird: The pages contain pictures embedded like e.g. Filename.jpg which were themselves uploaded using Semantic Forms and adding them directly to namespace File (not via the form used to edit the page - uploadable). So if one wants to edit the page it tries to edit it with the form used for uploading the picture. However the existence of the picture does not involve adding a category which uses the form used for uploading the picture. --&#91;&#91;kgh&#93;&#93; (talk) 20:53, 24 July 2014 (UTC)


 * Oh man, just found the issue with the duplicate form assignment. The template of the page included a semantic query searching for a picture within the category which itself is using the form for uploading files. So this was actually the only file not embedded the classic way. So I am glad that this is sorted out now. Still the issue with the duplicate listing remains. I have to note that this only started to be a problem after the page was approved. Before that the query did not cause the "form duplication" issue. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 21:14, 24 July 2014 (UTC)


 * Yeah...that sounds like the issue. Sometimes I encounter similar issues when a there is a conflict between categories defining which form a page should use with Has default form::form-name and templates defining which form the page should use via Page has default form::form-name . See Extension:Semantic Forms/The "edit with form" tab. Also, the new version of Approved Revs is still being reviewed...hopefully released any day now. --Jamesmontalvo3 (talk) 21:22, 24 July 2014 (UTC)


 * Ah, there is still an unmerged commit on the way. Now I get it. :) Still wondering why Approved Revs causes the issue to appear in the first place. Semantic Forms on itself was happy with the query containing the "evil" category. However, I should avoid unnecessary code in my queries right from the start. --&#91;&#91;kgh&#93;&#93; (talk) 21:40, 24 July 2014 (UTC) PS Will move the new version is as soon as its ready to go. :)


 * The changes are pretty substantial. Most notably you can now define specifically who can approve what content (by NS, category, page, SMW property) and files are approvable (approved version of images are displayed on pages). --Jamesmontalvo3 (talk) 22:02, 24 July 2014 (UTC)


 * WOW, this sounds indeed like substantial changes are in the making. :) This will definitively widen the use cases for this extension. --&#91;&#91;kgh&#93;&#93; (talk) 17:47, 26 July 2014 (UTC)

Sent Yaron my modification of ApprovedRevs
I modified your code with the following features my group required For all features to work a couple of scheduled jobs are required. One to mark old documents as expired and another to periodically send emails to owners of expired, rejected, and force-reviewed documents. I hope you find it useful. Please let me know if sending Yaron the code is the best way to contribute or if you have any questions.
 * Email notifications
 * Document expiration
 * Group ownership of categories (for email notifications)
 * Ability to restrict approval privs for members of specific mediawiki groups to specific categories
 * Ability to restrict approvers of specific categories to members of specific mediawiki groups.
 * Ability to reject document edits
 * Ability to "force-review" documents