Difference between revisions of "Extension talk:PublicRevision.php"

From Organic Design wiki
(change info to legacy)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 +
{{legacy|This is obselete now as the [[MW:Extension:FlaggedRevs|FlaggedRevs extension]] is now in use for the same purpose. See also [[News:Help:Page validation]] for more information.}}
 +
 
== Summary ==
 
== Summary ==
 
*Set PublicRevision: namespace permissions
 
*Set PublicRevision: namespace permissions

Latest revision as of 09:06, 2 March 2009

Legacy.svg Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.

Please refer to [[This is obselete now as the FlaggedRevs extension is now in use for the same purpose. See also [validation] for more information.]] instead.


Summary

  • Set PublicRevision: namespace permissions
  • Add hook to modify $_REQUEST
  • Add hook to add set revision button to edit form mw:Manual:Hooks/EditFilter
  • If user is allowed to edit PublicRevision: then the edit form button will appear
  • Examples for LocalSettings.php
  • Example pages with three tier permissions (eg editors, moderators, public).

See also

The method I have in mind

There may be a better way to implement this, but my initial thoughts were to have a namespace, maybe "PublicRevision", which is therefore easy to apply specific edit permissions to which holds the current public revision-id of articles of the same name in the Main namespace (for articles for which the public version is not the current revision).

An extra action button could be added to give a simple means of making the revision being currently viewed into the revision the public will see of that article.

I've had a bit of a look at the database schema and another angle might be via the cache. The cache expiry could perhaps be managed so as to hook an extension before the expire logic. Then the extension decides if a page cache is expired depanding on some policy. The default policy would be not to expire the cache and continue to serve the same page. Not sure how other page actions would interact with this though. --Rob 20:13, 25 September 2007 (NZST)
For the actual specifics of how the default view is maintained at a particular version I think it would be easiest to just push an oldid key into the $_REQUEST hash rather than dealing with the complexities of the caching system. But if the oldid method has problems then I'll check out that possiblity. --Nad 20:19, 25 September 2007 (NZST)

The method works, but we need to refine the idea a bit

I've tested the method of writing an oldid into $_REQUEST if the requested title has an associated article in the NS_PUBLICREVISION namepsace containing the oldid to use. This method works correctly, but it raises a question as to how the extension should operate with respect to editing. The edit view of the article can't be held back too because the editors need to be collaborating on the current state, so this extension probably applies to sites where there's three levels of user; public, editors and moderators. If the public were allowed to edit it would make the extension pointless. People with the ability to edit should be able to see the real current revision, but would not have access to edit articles in NS_PUBLICREVISION, and the revision would only be held back if the user is anonymous.

How about linking in with the idea of protected pages. My question is: Are controlled revisions inclusive or exclusive. IOW are all pages held back until released, or are all pages released unless specifically held back. Maybe there needs to be a control on the edit form: "Publish this edit immediately". --Rob 09:55, 28 September 2007 (NZST)
Also, we need to have a template that notifies the user that the page revision they are viewing is not the most recent. This would only be displayed to logged in editors. The edit mode would of course display the most recent version.--Rob 11:24, 28 September 2007 (NZST)
I was thinking that editors would not see a held back version, but would see a notice that it was held back with a link to the public version --Nad 14:03, 28 September 2007 (NZST)

Testing the oldid method

As an example, revsision 48390 is a version of Sandbox from January which contains some musical notes which unfortunately don't render as a nice musical score anymore :-(. If you create the article PublicRevision:Sandbox and put 48390 in its content, then visit the sandbox, you'll see that it is successfully being held back to the specified revision and showing the musical notes instead of the current content of a pdf-book test.

Currently there are no permissions on the new namespace and it's being held back regardless of the action or the users permissions, but as a proof of concept it shows that this method of writing an oldid into the $_REQUEST hash works quite well.

Perhaps we can make the PublicRevision: namespace mediawiki only to modify with no edits from humans. Then the extension could use the page to keep track of the revision and implement whatever kind of policy is required (inclusive or exclusive). --Rob 10:05, 28 September 2007 (NZST)
Pages are not affected unless there exists an associated page in the NS_PUBLICREVISION namespace. It ties in with existing protection schemes by using a namespace so it can be made that for example only user in the moderator group can adjust the current public revision. (they wouldn't have to specifically adjust the PUBLICREVSION articles, it would be done via action links instead). --Nad 11:27, 28 September 2007 (NZST)
Also need to find a way to hide the previous<->next links at the top of the page so it looks like every other page. IDs: mw-revision-info and mw-revision-nav are the css for this and could be display:none'd. --Rob 11:35, 28 September 2007 (NZST)
Yeah I thought about that, not sure what the best and least hackish method would be for that yet --Nad 14:05, 28 September 2007 (NZST)

Initial Requests for this extension

Showing older versions until the newer version of an artical ain't released

from MW:Project:Support desk#Showing older versions until the newer version of an artical ain't released

OK, my English is not so good but I hope you'll understand me anyway.

I want to protect my articles of viewing by anyone except a special group. If anyone else is trying to watch these articel, protected by me, he will be shown an older version that was released earlier. It's a kind of quality management. As long the newer informations are not checked by anybody in that special group, the older version of this articel should be shown. Is there any extension or a possibility of MediaWiki to do that? —213.214.18.64 06:52, 24 September 2007 (UTC)

This is a popular request, but currently I don't think there is such an extension. --Nad 07:41, 24 September 2007 (UTC)
Actually there is MW:Extension:PageProtectionPlus, and MW:Extension:CrudeProtection that seem to address the issue here. Check these out. 72.149.111.10 12:39, 24 September 2007 (UTC)
Neither of those extensions appear to be addressing this requirement. The idea I believe is to limit the default public view of an article to a certain revision until a member of an authorised group releases it to either the current or a more recent revision. None of the current security extensions are dealing with revisions, but rather just deny access completely to certain content of all revisions. --Nad 22:20, 24 September 2007 (UTC)

Edit Verification

from MW:Project:Support desk/Archive 11#Edit Verification

Would there be any way to have a verification process for edits?

I have created a wiki for my high school (900 students), disabled registration, integrated it with our other account systems, and restricted edits to only local machines.

However, this is still not secure enough, in the opinion of the Superintendant, as well as his superiors.

Would there be any way to allow edits, but put them 'on hold' to be later verified and applied by an administrator?

Thanks for your time. —137.164.95.15 16:10, 12 September 2007 (UTC)

I've thought about that before but never implemented it, the way I would go about it would be to allow the edits to go through, but make articles default view stay at the older revision until authorised to move to the current state. --Nad 22:07, 12 September 2007 (UTC)
How would I go about doing that? I'm not very experienced with PHP, SQL, or WIkis, but I follow directions very well. ;) 137.164.95.15 16:04, 20 September 2007 (UTC)
You'd really need a reasonable amount of mediawiki programming experience to do it, but it's an extension which is on my todo list so I'll leave a comment here when I get round to making some progress on it. --Nad 21:01, 20 September 2007 (UTC)

Feature requests

This extension works well but needs a couple more things to make it really useful.

  • If you click edit on an article with a public revision the oldid is set to the PublicRevision and you end up editing the old version: It does make it quite clear that you are doing this with a warning notice, but the default action should be to edit the current version. Maybe the extension could check for the edit action and in that case, not change the oldid.
  • When you edit the page and want to preview it would be nice if the current version was displayed where action=preview also.

I have made a more sophisticated template for use with PublicRevision. The template is intended to be used in the skin at the head of every page. It does a group check, and then a has associated PublicRevision article and that article is not empty check and displays a notice to remind the user that there's tricky things going on.

--Rob 12:45, 12 October 2007 (NZDT)