Extension talk:Approved Revs/Archive 2013

Approved revs+ Translate extension=not working?

Hi, I am using Mediaiwki ver 1.19.2 with both Approved revs and Translate extension installed. I am having problem that unapproved changes are being published. All changes made on source page are being published regardless if its approved or not. It seems like Translate extension "blocks" Approved revs functionality. Anyone having the same problem? Can you use these two extensions together?

Do things definitely work correctly if the Translate extension is temporarily un-installed? Yaron Koren (talk) 17:35, 22 January 2013 (UTC)

After a lot of testing I come to this conlusion:

If adding Semantic Bundle require_once.. etc -statements for Approved revs before Translate-extension in my Localsettings.php the approve function is blocked out somehow and always shows latest revision even if not approved. If adding Translate first and Approved revs after the function "mark this page for translation" is blocked out on page. But approved version is working. So there is some kind of mismatching :/

Alright. But to re-ask my question: does Approved Revs work for you if Translate is not there? Yaron Koren (talk) 14:01, 24 January 2013 (UTC)

-Yes, only a problem when together with Translate.

Okay - and are you using the latest versions of both Approved Revs and Translate? Yaron Koren (talk) 15:47, 25 January 2013 (UTC)

Wrong page cached when saves made (1.19+)

I encountered what appears to be a bug when using ApprovedRevs in 1.19+.

When you save a page, the *APPROVED* page is the one that is cached for the current revision, instead of the current revision. This results in any attempt to view the current revision as seing the approved revision. Very confusing.

It appears this happens because of the behavior of ApprovedRevsHooks::setApprovedRevForParsing, since that function (erroneously, I believe) returns the approved revision text as the page save text (to make sure links and properties are saved).

(I've elided the patch provided by the OP, which is still available in the archive. --66.162.23.2 20:50, 11 February 2013 (UTC))

Sorry for the long delay on this. I finally tested this out, and I couldn't see a problem. Assuming you're still reading this - can this be reproduced consistently, or does it only happen sometimes? Yaron Koren (talk) 01:00, 4 January 2013 (UTC)

I'm not the OP, but I've just started using this extension and I can consistently reproduce it on MW 1.19.2 with ApprovedRevs 0.6.4. My ApprovedRevs are set up to apply to just one namespace. If you create a page in this namespace, then approve that revision, the latest revision is the approved revision and everything works as expected. However, if you then create one or more unapproved revisions, the "latest revision" link always shows the approved revision instead of the latest revision. However, if you use the revision browsing links to move back one revision, then forward one, the correct revision is displayed. The problem doesn't seem to consistently happen when the latest approved revision isn't the first revision for the page. --66.162.23.2 17:43, 6 February 2013 (UTC)

The problem persists in MW 1.20.2. Also, further testing indicates that this seems to consistently occur; it doesn't matter if the latest approved revision is the first revision or not. A notable feature about my wiki is that I use PHP wincache (via $wgMainCacheType = CACHE_ACCEL) and the file cache; this bug may not replicate without those on. I also cache load.php through IIS's dynamic output cache, though I don't really see how that would have any effect. --66.162.23.2 23:13, 6 February 2013 (UTC)

Okay. If it's not too much work, could you try temporarily disabling wincache (I doubt the other caches are involved) and see if the problem still happens? Yaron Koren (talk) 23:20, 6 February 2013 (UTC)

Interestingly, the problem seems to persist even with $wgMainCacheType = CACHE_NONE. --66.162.23.2 16:20, 7 February 2013 (UTC)

Reviving this discussion from the archive, as the problem still persists despite disabling the cache... which is rather odd. --66.162.23.2 20:50, 11 February 2013 (UTC)

Hi - did you try that patch, by the way? Yaron Koren (talk) 13:40, 12 February 2013 (UTC)

The patch seems to fix the issue, at least how I put it in by my reading of the instructions. What I did was comment out the ParserBeforeInternalParse hook, then add the patched function in as the ArticleEditUpdates hook. The OP's instructions were a little unclear on whether the ParserBeforeInternalParse hook should be set to the new function as well, but as the signatures are different, I assumed that wasn't his/her intent. At any rate, the patch seems to correct the issue. --66.162.23.2 18:22, 12 February 2013 (UTC)

Okay, that's great. And I'm pretty sure you did the right thing by removing the previous hook. Since that patch seems to just fix everyone's problems, and the code certainly looks cleaner than the old hook, I'll just add it in to the next version. By the way, if the original poster is reading this, please let me know who you are, so I can credit you! Yaron Koren (talk) 22:24, 12 February 2013 (UTC)

Hi, It seems to me that the current solution, basically breaks the ApprovedRevs extension on all cached systems; with the current solution, after a page is approved, instead of containing the approved revsion, the cache now contains the latest revision. If the problem that we're trying to solve is about going to a page from the history and seeing:
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
then it seems to me that the problem is actually that the link called 'Latest Revision' does not contain an oldid= so it's going to the approved revision, of course, since the point of ApprovedRevs is that when you go to a page with no oldid you'll see the approved revision. The solution is not to confuse the cache by putting the latest revision as the revision viewed when there's no oldid. Rather the solution is that if the approved revision is different than the latest revision then we need another link:
(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
The Approved revision link should have no oldid and the Latest revision link should have an oldid, and of course if one is already viewing the Approved revision then the Approved revision link can be blacked out. So basically I'm saying that the right page was cached, only the link is wrongly named, now the wrong page is cached. User:Trees 10:00, 28 March 2014 (UTC)

I agree that it would be nice to have links to both latest and approved revisions. But are you saying that simply changing the text in the link will fix the caching problem? Yaron Koren (talk) 14:45, 28 March 2014 (UTC)

Actually I realize that setting up the Approved revision link requires special handling of its (diff) link, and of when it is disabled. So it would probably be easier to first modify the Latest revision link (referred to as $lnk in Article::setOldSubtitle()) to contain the oldid of the latest revision, because anyway on an uncached system or a system where the cache was refreshed it's now going to the approved revision, not the latest revision, since there's no oldid. But I don't know how to do that in an elegant way.

But anyway, the patch mentioned above needs to be undone so that there is no longer a temporary state where the cache for the plain page with no '?oldid=' leads you to the non-approved latest revision. I don't actually know how to undo the patch, so on my system I've worked around it by clearing the page's cache immediately in the ApprovedRevsRevisionApproved, and ApprovedRevsRevisionUnapproved hooks, but that's obviously not a real solution. User:Trees 8:04, 30 March 2014 (UTC)

Allow a user to see its own edits and a question about new unapproved page

I'd add ability for a user to see its own edits. Another point: when a new page (unapproved page) is created by a user it can be seen by anybody. And I (an admin) see no way to approve it.

Well, I think it's important for everyone to see the same thing - if a user's edits haven't been approved and aren't being shown yet, that user should know about it. And you should be able to approve by going to the history page. Yaron Koren (talk) 17:08, 19 February 2013 (UTC)

Notification

I think it would be helpful to add a notification piece to this extension. This would notify users with the 'approverevision' permission that there is a revision that needs approving.

--Dgennaro 17:17, 27 February 2013 (UTC)

Agree... This will be a good Add-on if we can receive an email notification! Right now, I need to manually check everyday and sometimes when I forget for a couple of days, I then realize someone created an article 2 days ago and I wasnt aware of it. Would adding email notification be possible at all yaron?

Doing notification across all the different event types is tricky, but if you just want to be notified when new pages are created, there's fortunately an extension that already does that: PageCreationNotif. Yaron Koren (talk) 11:23, 1 April 2014 (UTC)

Required MW version >= 1.19?

The extension page shows MW 1.17 as minimum version. However, Approved Revisions 0.6.5 on MW1.17 appears to have regression issues with a previously fixed issue with >1.19-code. Moreover, I receive an error on the special pages Special:ApprovedPages and Special:ApprovedRevs:

“1109: Unknown table 'p' in order clause (localhost)”.

--Remco de Boer 17:53, 4 March 2013 (UTC)

Ah - that's too bad; backward compatibility is to hard to ensure, when I don't a wiki running that MediaWiki version to test against. I'm hoping that MW 1.18 is still supported. I changed the documentation to reflect that it no longer works with 1.17. Yaron Koren (talk) 02:52, 5 March 2013 (UTC)

Same problem is occuring with meiawiki version 1.19.6.

“1109: Unknown table 'p' in order clause (localhost)”.

Can you please suggest any solution to this problem. Thanks in advance.

Sorry, I just saw this now. Did you create the "approved_revs" table? If not, that might be the cause of this problem - you need to call update.php to create it. Yaron Koren (talk) 19:25, 25 July 2013 (UTC)

Hide message on all pages

Is there a way to hide the message "This is the approved revision of this page, as well as being the most recent" on each page. I only want a message shown when the approved page is not the most recent. --82.2.128.31 21:04, 17 March 2013 (UTC)

The easiest way, though it's a little bit of a hack, is to go to the page "MediaWiki:approvedrevs-approvedandlatest" on your wiki, and replace the current contents with a space (" "). Yaron Koren (talk) 01:04, 18 March 2013 (UTC)

Thanks Yaron, that works a treat --82.2.128.31 18:24, 18 March 2013 (UTC)

I tried your hack Yaron, but it doesn't work for me properly (MediaWiki 1.20.5 & ApprovedRevs 0.6.5). Everytime I replace the content with a space, like you said, I click on Save and the page gets a blank body. But if I go back to another page, it always shows me the message "This is the approved revision of this page, as well as being the most recent". But the hack works if I replace the content with another text like "test" or whatever. --213.208.5.2 13:48, 24 June 2013 (UTC)

Hm, maybe the behavior changed in MediaWiki. You could try " " instead. Yaron Koren (talk) 21:22, 25 June 2013 (UTC)

Thanks Yaron this works fine now :) --213.208.5.2 05:38, 26 June 2013 (UTC)

Creating redirects leaves behind an unnaproved page

If you are an admin and you move a page and leave behind a redirect, then it turns out that the REDIRECT works, but, the page with the REDIRECT on it is considered a new page and it is listed as unapproved on Special:ApprovedRevs&show=unapproved --Joshuagay (talk) 18:49, 26 April 2013 (UTC)

How do I approve all pages

I want to approve all pages whose approved revision is not their latest. Is there a way to do that automatically? --KonstantinDmitriev (talk) 07:31, 11 May 2013 (UTC)

Unfortunately, no. Yaron Koren (talk) 13:42, 15 May 2013 (UTC)

Missing MediaWiki:Approvedrevs-approvethisrev text

Small thing - (b10b172) doesn't come with any approvethisrev text - had to create page manually - easy but confused me initially and I ended up trying to hack code! --Md2017 (talk) 08:54, 25 May 2013 (UTC)

That's very strange - that message is there in the code. Yaron Koren (talk) 18:41, 26 May 2013 (UTC)

Thanks Yaron - I was trying to work out why the setArticleHeader/setSubtitle logic doesn't work for me. I am having great difficulty wrapping my head around the problem!

• Create new page: "No revision has been approved for this page. View the most recent revision.". Fine
• I click view revision and approve it. I see "This revision of the page has been set as the approved version." but also "Approve this revision." -uh oh.
• I then click "read" and see "This is the approved revision of this page, as well as being the most recent." (fine).
• I then make an edit, and see "This is the approved revision of this page; it is not the most recent. View the most recent revision" - fine. But when I follow the link to view the most recent revision I see the old subtitle:

Revision as of 23:08, 26 May 2013 by NJB (Talk | contribs | block)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

... but no "Approve this revision". I'm using 0.6.5 with MW 1.20.4. I have

$wgGroupPermissions['*']['viewlinktolatest'] = true;
// $wgGroupPermissions['sysop']['viewlinktolatest'] = true;
$wgGroupPermissions['*']['userCanApprove'] =  true;
$egApprovedRevsAutomaticApprovals = false;
$egApprovedRevsBlankIfUnapproved = true;
$egApprovedRevsShowApproveLatest = true;
$egApprovedRevsNamespaces = array(NS_MAIN);

Can you help? All worked beautifully with 0.6 and MW 1.17. Nick Md2017 (talk) 22:14, 26 May 2013 (UTC)

(Update) The following change to setArticleHeader restores the previous functionality:

$approvedRevID = ApprovedRevs::getApprovedRevID( $title );
if ( ! ( empty( $approvedRevID ) || ( $wgRequest->getCheck( 'oldid' ) && $wgRequest->getInt( 'oldid' ) != $approvedRevID ) ) ) {
// if ( ! empty( $approvedRevID ) &&
// 	! ( $wgRequest->getCheck( 'oldid' ) &&
// 	$wgRequest->getInt( 'oldid' ) == $approvedRevID ) ) {
	return true;
}

Oh, that's great that you discovered a solution. I'll look into adding this to the main codebase. Yaron Koren (talk) 21:56, 29 May 2013 (UTC)

I just checked in a change that's a little different, but should be logically equivalent, to what you suggested. I hope it works - please let me know if there's still a problem. Yaron Koren (talk) 04:12, 28 June 2013 (UTC)

Show the latest content with a warning sign if its not approved

Hi

I want to show the latest content of a page with a warning text, though the revision is not approved yet. Msg some thing like "This is the most recent revision of the page, but not approved yet". please advice?

Well, the latest contents are already shown if there's no approved revision. So the only addition would be a message at the top. Which is not a bad idea, as an optional feature - I'll look into adding it. Yaron Koren (talk) 12:38, 12 July 2013 (UTC)

Thanks Yaron

XML Exports (and dumpBackup.php) Ignore Approved Revs

Approved Revs does not appear to hook into the XML export system, so the latest revision is always exported whether it's approved or not.

When doing an XML export with the "Stable" flag, the following hook is used:

WikiExporter::dumpStableQuery

Alternatively, this hook could be used to modify the query for all exports to ensure Approved Revs is used (more of a "brute force" to ensure only the approved revision is exported):

ModifyExportQuery

Adding one or both of these hooks to Approved Revs would ensure that search results (if using Lucene) only use the approved revision. Unfortunately, I'm not familiar enough with the Approved Revs code, and I didn't have time to figure what code would be needed around these hooks. Yaron, would you have time to add this feature?

Thanks!

--Jlemley (talk) 13:28, 31 July 2013 (UTC)

Hi - it's good to know that Approved Revs doesn't work with the export stuff - I never thought to check the export. Unfortunately, fixing it may prove difficult. I looked into fixing Special:Export, using those hooks - unfortunately, the first hook doesn't seem to get called; the second one, which is rather similar, does get called, but its structure makes it hard to set the approved revision in the export. (And actually, the same is true for the first hook.) It involves changing around elements of an SQL query, but with the approved_revs DB table that's difficult, because it only stores rows for pages that are approved - so the query would need to get values from different tables for different rows - which I don't think is possible, with the current querying structure. Is there possibly some other hook that could be used? Yaron Koren (talk) 13:25, 1 August 2013 (UTC)

Have viewlinktolatest subtitle show announcement to unapproved version only

Hi Yaron,

I just tried this extension and its awesome! Simple and very effected. Does exactly what you want it to without overloading it with too many features. I love your work with this and it works wonderful with the semantic forms. :)

My Requests: (1) I like the 'viewlinktolatest' subtitle at the topic that tells users if an unapproved version is available. This is useful. However, when I have this enabled, it also shows the "This is the approved revision of this page, as well as being the most recent" subtitle too. I dont want that since its annoying as most of the articles are usually approved ones. Is there a way to show the subtitles is awaiting approval version message only and not the subtitle that says this is the approved version? It will be useful if we can change these 2 settings to true or false separately in LocalSettings.php (2) Also, I am trying to show the subtitles for logged-in users and sysops only. So how do I disable 'viewlinktolatest' subtitle for users not logged in?

Hi - I'm glad you like it! For (1), I agree that there should be a setting; for now, though, you can do this with a hack, by goint to the page "MediaWiki:approvedrevs-approvedandlatest" on your wiki, and replacing contents with " ". For (2), you can do that by setting the 'viewlinktolatest' permission. Yaron Koren (talk) 01:31, 2 September 2013 (UTC)

Hi Yaron, (1) The hack was a good idea. However, I went to the page "MediaWiki:approvedrevs-approvedandlatest" in my wiki, and replaced its contents with " ", but still it didint work. It was still showing the message even when this MediaWiki:approvedrevs-approvedandlatest page was empty with just a space in it. So for now I opened the ApprovedRevs.i18n.php page and removed the text for 'approvedrevs-approvedandlatest' and replaced it with " ". That seems to work. (2) Setting the permission worked. I actually tried setting the permission last night after reading the examples in the extension page but it wasnt working. Maybe I was too tired then. Anyhow, it works now and I added the following for it:

$wgGroupPermissions['*']['viewlinktolatest'] = false;

$wgGroupPermissions['user']['viewlinktolatest'] = true;

$wgGroupPermissions['sysop']['viewlinktolatest'] = true;

BTW - a big thumbs up for your great support. I am new to mediawiki and so far I only have experience with phpbb. So its a big change for me learning MW and out of all your extensions have been the most useful for me. So a big thank you Yaron! :)

Ah, great - I actually had " " in my my comments, but I forgot to HTML-escape it (just like you did, apparently :) ). I'm glad you figured it out. And thanks! Yaron Koren (talk) 13:27, 3 September 2013 (UTC)

Concepts for Enhancing ApprovedRevs

Has anyone looked into what it would take to enhance the self-owned-pages concept in ApprovedRevs? I'd like to use that feature on my organization's wikis, but we'd need to be able to change who the owner is if the previous owner was no longer a wiki user. Also having multiple users owning a page would be ideal.

Looking at ApprovedRevs_body.php, in the userCanApprove function, it seems like it would be pretty easy to add a database table with fields "page" and "user_who_can_approve", and add a check to that somewhere in the if-else statement. Or perhaps make a page in the MediaWiki namespace structured something like:

My page name | User:Dquayle, User:Bdole, User:Hclinton
Another page name | User:Sstallone
Yet another page | User:Bert, User:Ernie

Has anyone done any work in this direction? Any better ideas? Suggestions? What about being able to define a permission group able to approve in one namespace, and another group able to approve in another namespace?

Thanks.

--Jamesmontalvo3 (talk) 22:38, 3 September 2013 (UTC)

That's not a bad idea - especially the wiki page implementation: it's a simple interface, and quite powerful. Potentially, the "owned" area could be an individual page, a category or (as you note) a namespace; and the owner could be either an individual user or a user group. If the syntax could handle all of those things, I think it could be a complete solution. Any interest in working on it? :) Yaron Koren (talk) 02:03, 4 September 2013 (UTC)

Yeah I'll take a hack at it. The per-page and per-namespace method I see working fine. By category would work in many cases, but some people would be able to get around it. If a person was an editor, and had revision-approval rights for one category but not another, they could add the category they do have to any page then approve the rev. It's somewhat of an edge case, and requires malicious intent from a trusted person (they were granted approval rights to one category).

--Jamesmontalvo3 (talk) 03:17, 4 September 2013 (UTC)

That's great! It's true that category rights can be abused easily, but then again users can do any number of malicious things, if they wanted to... I still think it would be a useful component. Yaron Koren (talk) 13:23, 4 September 2013 (UTC)

I haven't gotten around to working on this update yet, but it's an approaching priority for me so hopefully I can start today or tomorrow. But, another thing I'd like to do is add the capability to have approved files/images. The extension description says it's not recommended to use ApprovedRevs on files. Any thoughts on how difficult it would be to make it work with files?

--Jamesmontalvo3 (talk) 17:38, 11 September 2013 (UTC)

I don't know - from what I recall, I looked into that before and saw that it would require changes to the image-display code in MediaWiki; at the very least, adding some hooks. At that point, I gave up on the idea. But I agree that it would be a great feature to have, and I'd be happy to provide support if you wanted to look into it further. Who knows, maybe by this point core MediaWiki no longer requires modification to get this feature working. Yaron Koren (talk) 19:14, 11 September 2013 (UTC)

So I'm going to make it so ApprovedRevs gets its permissions info from MediaWiki:ApprovedRevsPermissions. You'll be able to determine who can approve pages at the namespace, category, and page level. The criteria for who can approve a page can be individual users, user groups, and some special cases (I'll explain below). ApprovedRevsPermissions will look something like this:

==Namespace Permissions==
Blog | SpecialApprover:Creator
User | SpecialApprover:Self

==Category Permissions==
Category:Computer Science Lesson Plans | Group:Computer Science Faculty
Category:Physics Lesson Plans          | Group:Physics Faculty

==Page Permissions==
Theory of Relativity 101 | User:Albert Einstein
+PHP Development 101     | User:Yaron Koren
Main Page                | User:Jamesmontalvo3, User:Yaron Koren 

So you can assign the group "Physics Faculty" to be the only people able to approve pages with category "Physics Lesson Plans", or you can assign a user to watch a specific page. "SpecialApprover:Creator" means the person who created the page, and "SpecialApprover:Self" would only apply to the User namespace and provide the same functionality the current ApprovedRevs does.

I plan to make each section override any previous section. So a page defined under ==Page Permissions== would restrict that page to being approved only by people/groups listed, even if that page would have had a different definition based upon the Namespace or Category sections. So above, the page "Theory of Relativity 101" can only be approved by User:Albert Einstein, even though that page has category "Physics Lesson Plans" and otherwise could only be approved by people in the group "Physics Faculty". However, by adding a plus (+) before the definition it will add the definition to any current definitions. So "PHP Development 101", which has category "Computer Science Lesson Plans" can be approved by either: people in the group "Computer Science Faculty" or by User:Yaron Koren.

I have some additional SpecialApprover concepts I may or may not implement right away:

• SpecialApprover:No Repeat - most recent approver cannot approve (so you get new people approving)
• SpecialApprover:Significant - Only people who have made significant contributions prior to current approved rev can approve it
• SpecialApprover:Property:<property name> - So you can define a property <property name> that points to a user or users who can approve the page

Any thoughts on this implementation? I still haven't determined how exactly I'm going to do it...I just wanted a clean administration method so I started with that.

--Jamesmontalvo3 (talk) 22:20, 11 September 2013 (UTC)

This sounds great - it looks like this project is really moving in the right direction. A few thoughts:

• I didn't think at first that the section headers would be needed, but they do make a bunch of things easier. One note on that, though, is that you probably don't need "Category:" in the content of the "Category" section, since that's implicit.
• I would consider using the INI file format, instead of something that looks like wiki-text - so it would be "[a]" instead of "==a==", and "b = c" instead of "b | c". PHP already has built-in parsing for INI files, so that part would be easier. It wouldn't look as nice on the page, but then again the page won't look that good anyway.
• The "+" thing is interesting, and it makes sense, but it might be overkill - a feature that might end up being rarely used. Personally, I would just have the permissions get overrided completely, so that admins have to manually add in all groups. It makes the handling simpler, and if a lot of people complain, then the "+" feature could be added.
• I don't see the need for any of those three additional concepts. But maybe it's not worth talking about that part yet.

Concur, the category prefix is unnecessary. INI syntax is a good idea, and it could be made to look pretty by wrapping the config portion in <syntaxhighlight lang="INI">...</syntaxhighlight>. On my wiki I feel like this permissions page is going to get pretty complicated, so having a page that's human readable without opening the editor is a good thing.

The "+" thing is a semi-requirement for us. We have a 1000+ page wiki with lots of different information, and the only place we plan on using ApprovedRevs at this point is for our lesson plans. Each lesson plan has one or two owners that need to be able to approve changes, but we also want a small group of people to be able to approve any lesson plan.

Agreed that the first two extra "SpecialApprover" options aren't likely useful. I was just brainstorming. I think that the third could be really good though. It would allow you to set a property (like [[Lesson Plan Owner::User:Jamesmontalvo3]]) on a page and have the value of that property be the person (or people) who can approve the page. I changed the name slightly, but it's implemented below.

[Namespace Permissions]
Blog = SpecialApprover:Creator
User = SpecialApprover:Self
 
[Category Permissions]
Computer Science Lesson Plans = Group:Computer Science Faculty
Physics Lesson Plans          = Group:Physics Faculty
Biology Lesson Plans          = SpecialApprover:UserProperty:Lesson Plan Owner
 
[Page Permissions]
Theory of Relativity 101 = User:Albert Einstein
+PHP Development 101     = User:Yaron Koren
Main Page                = User:Jamesmontalvo3, User:Yaron Koren

--Jamesmontalvo3 (talk) 02:48, 12 September 2013 (UTC)

Okay, cool, this is really coming together. More thoughts:

• If you have a need for '+' already, then it should go in - it's ideal when the person developing software is also someone who needs to use that software.
• Speaking of needs, though, I don't see the need for "SpecialApprover:Self". Wouldn't this only make sense for the "User" namespace? In that namespace, users already can always approve their own pages - and I can't think of a situation when that wouldn't be the case.
• The "SpecialApprover:UserProperty" thing now makes more sense, and though it takes kind of a mental leap to consider adding an SMW dependency to this extension, it does seem like a clever feature. One thought, though: instead of "SpecialApprover:UserProperty:Lesson Plan Owner", could it just be "Property:Lesson Plan Owner"? It's cleaner, and possibly easier to understand.

What do you think? Yaron Koren (talk) 13:27, 12 September 2013 (UTC)

My thinking for the SpecialApprover:Self was thinking that I'd consolidate the methods of giving approval permissions. Rather than using $egApprovedRevsSelfOwnedNamespaces you'd use the permissions page. Also, $egApprovedRevsSelfOwnedNamespaces can only be modified by people with server access, whereas any sysop could administer this. That also brings into question whether or not to keep the "approverevisions" permission that needs to be granted to groups. Does it make sense to have an alternate method to grant people blanket approve-permissions? It seems simpler to just have the permissions page. Perhaps there should another section on that page. See the "All pages" in the INI content below for possible implementation. What do you think?

Agreed that "Property:Lesson Plan Owner" is cleaner. Along those lines, I think I'll strip the "SpecialApprover" from "Self" and "Creator" and any of the others that are implemented. See below.

All pages = Group:sysop, Group:approvers

[Namespace Permissions]
Blog = Creator
User = Self
 
[Category Permissions]
Computer Science Lesson Plans = Group:Computer Science Faculty
Physics Lesson Plans          = Group:Physics Faculty
Biology Lesson Plans          = Property:Lesson Plan Owner
 
[Page Permissions]
Theory of Relativity 101 = User:Albert Einstein
+PHP Development 101     = User:Yaron Koren
Main Page                = User:Jamesmontalvo3, User:Yaron Koren

--Jamesmontalvo3 (talk) 14:34, 12 September 2013 (UTC)

Cool - the syntax looks a lot better.

• I agree that consolidation in general is good, but I still don't see the need for the "Self" thing. It seems to me that every wiki should have this permission set - and so there's no reason to even make it a setting.
• The "All pages" thing seems reasonable. If/when this entire "settings page" feature becomes fully integrated, it does seem to make sense to deprecate both $egApprovedRevsSelfOwnedNamespaces and the "approverevisions" permission. Yaron Koren (talk) 15:00, 12 September 2013 (UTC)

Agreed that if page approvals are enabled for the User namespace, wikis will probably always want to allow users to approve their own pages. However, I don't want approvals turned on any namespace that it's not absolutely required on my wiki. We really only want it for the sake our lesson plans, which management has dictated shall be blessed by the lesson plan owner before displaying new revisions. In our particular case adding approval requirements to other pages is additional bureaucracy that we don't need at this point. Adding it to user pages will cause additional confusion to some users ("I updated my user page...why didn't it show up?").

I also don't want to make ApprovedRevs enabled on the entire Main namespace. I want it only enabled for lesson plans. I could either define a new namespace "Lesson Plans" or I could make it done by "Category:Lesson Plan". Whether or not a given page requires approvals will be determined implicitly by whether or not there is a rule in the INI page for that rule. So doing the following would turn approvals on for the Lesson Plan and User namespaces, and sysops could also approve in either case.

All pages = Group:sysop

[Namespace Permissions]
Lesson Plans = Group:Lesson Plan Owners
User = Self         (note: including just for example...we personally don't want a User namespace definition)

[Category Permissions]

[Page Permissions]

Doing the following would turn it on only for category "Lesson Plans". With this method we could add a new lesson plan without adding specific owners, and at least the Lesson Plan Superusers would be able to approve it. Also note that if any of the pages in the [Page Permissions] section happen to not be Category:Lesson Plans, they will also have approvals required...so it's not going to enforce a restriction to only having approvals in Category:Lesson Plans.

All pages = Group:sysop

[Namespace Permissions]

[Category Permissions]
Lesson Plans = Group:Lesson Plan Superusers

[Page Permissions]
+Biology 101 = User:John 
+Physics 101 = User:Sally, User:Allen, User:Steve
+Physics 201 = User:Sally, User:Allen
Physics 301 = User:Sally

In the case of Physics 301 I left off the + to indicate that only Sally is educated enough to make lesson plan decisions on this advanced course. The rule allowing Lesson Plan Superusers is overridden here. That said, I think sysops should still be able to approve...so the All Pages definition should not be able to be overridden. Thoughts?

--Jamesmontalvo3 (talk) 15:53, 12 September 2013 (UTC)

Ah, I didn't realize that you meant for this page to also define which namespaces/categories/pages are approveable in the first place. That's an interesting idea - it definitely adds a lot of flexibility, but on the other hand, it might not be necessary: just because a page is approveable, doesn't make it part of the approval system - that doesn't happen unless it has an approved revision already, unless you set $egApprovedRevsBlankIfUnapproved. But maybe that additional flexibility is useful anyway. If this page is used to defined approveability, though (which would presumably also mean deprecating $egApprovedRevsNamespaces), then you would need to also allow for specifying a category/namespace/page name on a line by itself, without any user/group/property name. So, given that, I would say that you still don't need the "Self" thing. Yaron Koren (talk) 16:41, 12 September 2013 (UTC)

Why would you need to be able to specify a namespace/category/page on a line without user/group/property? If you didn't give a user/group/property who would be able to approve that namespace/category/page? I suppose people defined in "All Pages" would be able to do so...but for backwards compatibility I'd say instead you put in the "Namespace Permissions" section "Main = Group:sysop". Maybe I should make that the default for the INI page.

--Jamesmontalvo3 (talk) 18:02, 12 September 2013 (UTC)

Yes, the "All pages" setting would be the default. What do you mean by "backwards compatibility"? Yaron Koren (talk) 18:19, 12 September 2013 (UTC)

This thread is kind of insane...By backwards compatibility I meant that it would be ideal for the extension to work with minimal reconfiguration when someone upgrades from a previous version.

I've got a first rev of the code...It's not throwing a ton of PHP errors anymore, but as of this writing I have not tested to see if it's actually working yet. It's probably riddled with bugs at this point. You can take a look at my github repo.

--Jamesmontalvo3 (talk) 23:39, 12 September 2013 (UTC)

Hi - I know what backwards compatibility means, I just don't understand how it relates to the question of whether lines without a user/group/property should be allowed. Anyway, your code looks good so far, and I'm looking forward to when it's ready. Yaron Koren (talk) 14:22, 13 September 2013 (UTC)

My explanation of what I meant by backwards compatibility was incredibly vague. Sorry, I wasn't trying to imply that you didn't know what the generic term meant...I just lacked the ability to explain myself after a long day figuring the extension out. I think I misused the term backwards compatibility anyway, when I really just meant that we should aim that the new version of the extension be a drop-in replacement for the old version without additional configuration...so the approvedrevs-permissions page should mimic the old versions default configuration.

This morning I pushed a working copy to github and I just pushed another rev that enables the "Property:Username Property" method of adding approvers. Using the INI syntax was an awesome idea for many reasons (thanks for the suggestion), but an awesome thing I just noticed is that I can use INI comments to comment the approvedrevs-permissions page. I have this running on our development server and it appears to be working very smoothly. I have only tested it on MW 1.21 on PHP 5.4 thusfar. This morning I did some quick tests on PHP 5.3 and it worked then, but I've changed many things since then.

--Jamesmontalvo3 (talk) 20:23, 13 September 2013 (UTC)

Okay, that makes more sense - though I still don't see the connection to that one specific issue. :) Maybe it'll make more sense when I try it all out. Yes, comments are another good reason to use INI format. I'm glad it's coming along well! Or maybe it's already ready. Yaron Koren (talk) 20:44, 13 September 2013 (UTC)

Yes, I would say it's ready. I'm not using it in production yet, but will be shortly after I get a few people I work with to test it out. In addition to all the permissions things we've discussed, I also made the approved rev within the history page stand out a bit more.

--Jamesmontalvo3 (talk) 19:53, 16 September 2013 (UTC)

Any progress on this? Is the source available anywhere? Sounds interesting. EDIT: Ah OK, there it is: https://github.com/jamesmontalvo3/MediaWiki-ApprovedRevs

--Jlerner (talk) 19:56, 1 January 2014 (UTC)

Magic Word

Hello, I would like to print out some special text on a special place in an article depending on wether the article is the latest approved one or not. Conditional text seems to be possible via ParserFunctions. But i couldn't find a way to check wether the revision is the latest approved one or not.

Any ideas? --Finswimmer (talk) 07:53, 9 September 2013 (UTC)

That's an interesting idea - I don't know if it's possible, other than with some hack; it might require creating a new parser function, like #if_latest_is_approved. Out of curiosity, what kind of text do you want to display? Yaron Koren (talk) 17:33, 9 September 2013 (UTC)

I don't think that is absolutly necessary that ApprovedRevs give me a parser function (of course it would be nice). I think it's enough if there is some kind of magic word/Variable that gives back a status. I use mediawiki for a quality management system. And there i have on each site in infobox where i would like to print out whether this site and revision is approved. --Finswimmer (talk) 17:48, 9 September 2013 (UTC)

I'm working on some updates to ApprovedRevs now and will take a look into this. I think a parser function like {{#RevsSinceApproval: {{{PAGENAME}}} }} would be ideal. This would return 0 if the most recent rev is approved, and otherwise would give you the number of unapproved revs. Using a parser function would allow integration into a Semantic MediaWiki ask query so you could easily query for all pages within a category that have a RevsSinceApproval greater than 0.

Another thing that might be nice is a method to show how long approvals have been pending. Maybe {{#ApprovalPendingLength | {{PAGENAME}} | date_format }}. The date_format could allow formatting using PHP date formats. I think length of time since first revision after most recent approval is the value we'd want returned. Thoughts on this? Would you need this capability?

--Jamesmontalvo3 (talk) 14:55, 12 September 2013 (UTC)

Your ideas sound great and could make my workflow much easier.

What about a variable that gives back the Revisionid of an approved article?

I'm thinking about another problem. But I'm not sure whether your extension is the right one for solving it. It would be nice, if someone who edit a page could leave some kind of magic word, that the article is now ready for revision. So he could work on it for a time (and create new versions of the site) and the person who should do the revision sees the article on a list not until it's ready for revision.

Thanks a lot for your great work! --Finswimmer (talk) 15:57, 15 September 2013 (UTC)

Just some more brainstorming about a function"Request for approval":

I guess a "magicword" is not the right way. It's better if one could mark a revision for approval in the same way it is marked as approved. For those who don't need such a function the possibility to autorequest just like autoapprove would be nice. Defining userrights for requesting would be nice as well --Finswimmer (talk) 16:37, 15 September 2013 (UTC)

Only owner of the article can approve revision

Dear all, is it possible if only owner (the one who create the article) who can approve the revision? so all of users can edit but only owner of the article who can approve revision.

Thanks

Yes - see here. Yaron Koren (talk) 15:51, 20 October 2013 (UTC)

Database error

Hello all, i dont know why i got this error everytime i click on view history of article

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "". Database returned error "1054: Unknown column 'revision.rev_user_text' in 'field list' (localhost)".

did i miss something?

thanks

Have you run the update.php maintenance script? --Remco de Boer 09:04, 28 October 2013 (UTC)

How to run the script?

Have a look at mw:Manual:Maintenance_scripts#Running_the_scripts. --Remco de Boer 10:38, 28 October 2013 (UTC)

egApprovedRevsBlankIfUnapproved not working

I've been reading up on how to solve this problem but can't seem to get it working, I have the $egApprovedRevsBlankIfUnapproved = true; in the LocalSettings.php file but pages created by a user is shown to everyone even visitors that haven't signed in.

What could be the problem? The page that have been created by a user and is in the "Unchecked" state.

# FlaggedRevs options
$egApprovedRevsAutomaticApprovals = false;
$egApprovedRevsBlankIfUnapproved = true;
$egApprovedRevsShowApproveLatest = true;

-- 10:34, 30 October 2013 (UTC)

What versions of Approved Revs and MediaWiki are you using? Yaron Koren (talk) 13:00, 30 October 2013 (UTC)

I'm using MediaWiki 1.21.2 and ApprovedRevs 0.6.5 --Gonace (talk) 14:32, 30 October 2013 (UTC)

Sorry for the delay. I just tried this out, using MW 1.22 and AR 0.6.5, and that same group of settings, and everything worked fine - the new page I created was unapproved, and it showed up as blank. I doubt the small MediaWiki version difference is the issue... maybe you have some other settings in LocalSettings.php that are overriding those? Or maybe those settings are being done before the inclusion of AR (they need to be after)? Yaron Koren (talk) 23:25, 5 November 2013 (UTC)

Categories pages not displaying approved/unapproved links

Hi, in our wiki we are using CategoryTree extension & we devided articles into categories and sub categories. I have installed ApprovedRevs extension i cant see approve/unapprove links in ViewHistory for categories, it is visible only for pages. Is it possible to approve/unapprove categories also?, plase help...

Hi - unfortunately, category pages can't be brought into the approval system, due to their special implementation in MediaWiki. Yaron Koren (talk) 14:07, 27 December 2013 (UTC)