Talk:GroupWikiBase

Hiding partial content from Search Results

 * For some reason, even if the "read" permission of sensitive articles was denied for the current user, search results include the denied articles with the partial contents. The quick and dirty fix for this is simply hide the partial contents from the Search Results. This way, the article is still searchable but yet access to the article is controlled by GroupWikiBase extensions.

 foreach ( $lines as $line ) { if ( 0 == $contextlines ) { break; } ++$lineno; if ( ! preg_match( $pat1, $line, $m ) ) { continue; } --$contextlines; $pre = $wgContLang->truncate( $m[1], -$contextchars, '...' );
 * To do this, on /Includes/SpecialSearch.php, Replace the following codes in showHit function:

if ( count( $m ) < 3 ) { $post = ''; } else { $post = $wgContLang->truncate( $m[3], $contextchars, '...' ); }

$found = $m[2];

$pre=strip_tags($pre); $post=strip_tags($post);

$line = htmlspecialchars( $pre . $found . $post );

$pat2 = '/(' . $terms . ")/i"; $line = preg_replace( $pat2,  " \\1 ", $line );

$extract .= " {$lineno}: {$line} \n"; } 

 // Hide hit if it is for internal KB which might have some sensitive information on the search result... $currentURL=$_SERVER["REQUEST_URI"]; //You can repeat the following to differentiate the behaviours per wiki but want to have 1 source code... if (eregi("/{WikiRootYouWantToHidePartialContent}/", $currentURL)) {$hideHit = true;}
 * to the following:

if (!$hideHit) { // hideHit Begin foreach ( $lines as $line ) { if ( 0 == $contextlines ) { break; } ++$lineno; if ( ! preg_match( $pat1, $line, $m ) ) { continue; } --$contextlines; $pre = $wgContLang->truncate( $m[1], -$contextchars, '...' );

if ( count( $m ) < 3 ) { $post = ''; } else { $post = $wgContLang->truncate( $m[3], $contextchars, '...' ); }

$found = $m[2];

// 20070219 ypae strip HTML tags... http://ca3.php.net/strip_tags $pre=strip_tags($pre); $post=strip_tags($post);

//// ypae Future usage to restrict the content if it is restricted...

// $searchResultUserCanRead = null;

//// Do some magic here and set $searchResultUserCanRead=true or false;

// if ($searchResultUserCanRead) { // $line = htmlspecialchars( $pre . $found . $post ); // } else { // $line = "**** Not allowed to read the content ****"; // } //// Original $line: $line = htmlspecialchars( $pre . $found . $post );

$pat2 = '/(' . $terms . ")/i"; $line = preg_replace( $pat2,  " \\1 ", $line );

$extract .= " {$lineno}: {$line} \n"; }  } // hideHit End 

Ypae 23:23, 5 March 2007 (UTC)

another option
I've written a much simpler patch that prevents restricted pages from showing up in searches; I have tested it only lightly as of yet, so please let me know if any problems are found. I have documented it here (in living color!). --Woozle 18:21, 20 March 2007 (UTC)

Automatically search custom namespaces if you are in matching groups
 function setNamespaces( $namespaces ) { // ypae Custom Namespace search automation Begin. global $wgUser,$wgExtraNamespaces; $customNamespaces = array; foreach ($wgUser->mGroups as $group) { // In all current user's group foreach ($wgExtraNamespaces as $nsnum => $val) { // In all CustomNamespaces if ($group == 'wiki'.$val) { // If there is any matching wiki* group if (!in_array($nsnum, $namespaces)){ // If it is NOT already selected $customNamespaces[$nsnum] = $nsnum; } } } } $namespaces = array_merge($namespaces, $customNamespaces); // Merge default $namespaces + customNamespaces with group membership... // ypae Custom Namespace search automation End $this->namespaces = $namespaces; }   $namespaces .= " {$name} \n";   // ypae Custom Namespace search automation Begin. global $wgUser,$wgExtraNamespaces;
 * By default, the search scope is inherited by $wgNamespacesToBeSearchedDefault per user at the user ID creation and let the users to change it as they wish via my preferences link. If you utilize namespaces and group memberships to control permissions extensively, you may want to automate the search scope depending on their group membership.
 * For example, let's say some users are part of "wikiCustomNS1" group and there is CustomNS1 namespace. When they search certain keyword, not all users checked "CustomNS1" on the search preference and ended up fail to display the article under CustomNS1 namespace. The following will make any users in wikiCustomNS1 group always search CustomNS1 regardless the users' preferences:
 * On \Includes\SearchEngine.php, replace setNamespaces function as following:
 * On /Includes/SpecialSearch.php, right before the following lines:
 * Add the following:

foreach ($wgUser->mGroups as $group) { // In all current user's group foreach ($wgExtraNamespaces as $nsnum => $val) { // In all CustomNamespaces if ($group == 'wiki'.$val) { // If there is any matching wiki* group if ($nsnum==$ns) { // If current namespace index is matching with $nsnum $checked = ' checked="checked"'; // set check box checked. } } } } // ypae Custom Namespace search automation End.

$namespaces .= " {$name} \n";  I hope that this helps. Ypae 19:21, 5 March 2007 (UTC)
 * if you want to have different group prefix other than "wiki", you can find and replace 'wiki'. to whatever you want.

Displaying Protect Tab on new article with certain condition(Namespace or Prefix, etc.)
Hello,

I installed GroupWikiBase and I found that Protect Tab is only allowed to sysop in the first place and available to the regular user once sysop give specific group or user a permission to manage it.

My intention is to make Protect tab available on the following conditions:


 * If the user is on a custom group (e.g. wikiNS1) while he or she is trying to create a page on the patching namespace
 * (Example Title: NS1:Protected Page but all users in wikiNS1 group can change Protection settings)


 * If the user is on a custom group (e.g. wikiGroup1) while he or she creates a page with [Group1] header.
 * (Example Title: Group1--Protected Page but all users in wikiGroup1 can change Protection settings)

As the example title stated, I want the end user to control over the protection for the predefined patterns on the title so that they can self-serve the protection control instead of asking sysop to assign the user's group (or user himself) to allow everything then they do whatever they want.

With my limited coding skill, I came up with the following solution:



// ypae Protect/edit permission override Begin if ( $titleObj->getNamespace >= 100 ) {   // if it is custom namespace $customNamespaceName= $titleObj->getSubjectNsText; //Get custom namespace name; foreach ($userGroups as $group) { if ($group != "wikiPublic") { if ($group == "wiki".$customNamespaceName) { //allow Protect/edit action temporarily $wgLoggedInPermissions = array('execute','read','edit','create','createpage','createtalk','protect', 'upload','reupload','reupload-shared','minoredit',); // 'protect' is added. } } } } // Get titleString; $titleName = $_GET['title']; if (eregi('--',$titleName)) { // if -- keyword is detected... $titleElements=explode('--',$titleName); $titleGroupName = $titleElements[0]; // get group name foreach ($userGroups as $group) { if ($group == "wikiPublic") { // skip if current local wiki group to check is wikiPublic. } else { if ($group == "wiki".$titleGroupName) { //echo "group is not wikiPublic and same with "."wiki".$titleGroupName.""; //allow Protect/edit action $wgLoggedInPermissions = array('execute','read','edit','create','createpage','createtalk','protect', 'upload','reupload','reupload-shared','minoredit',); // 'protect' is added. } } } }

// Protect permission override End

// check global group permissions (if none of the above apply) if (inGroupPermissions($userGroups, $action)) return $result = true; // if (in_array('sysop', $userGroups) && $action != 'userrights') //  return $result = true;

return $result = false; }




 * All group names start with "wiki" (e.g. wikiMyGroup1, wikiMyGroup2...)
 * I created wikiPublic group and put everyone in it (actually this was automated by using LDAP Extension) and skip override logic for "Public group" membership.

Please make the logic even better with your PHP expertises.

Thanks!

Ypae 17:10, 12 February 2007 (UTC)

Login problem after installation?
Hello, I installed GroupWiki_base and encountered a couple of problems/questions. The Wiki installed successfully but when I try to view pages I am redirected to Special page - Login Required. When I click on the login link (which takes me to the https://php.radford.edu/~rsheehy/groupwiki_base/index.php?title=Special:Userlogin&returnto=Main_Page) I receive a blank page. I added the suggesed lines below and still no luck. Any suggestions.

From the little information I have found it seems that GroupWiki may do exactly what I would like (give the ability of instructors to restrict editing of pages of other collaborative groups, but still be able to view those pages). Is there a simple way to set up groups and manipulate membership via text files? Any documentation would be appreciated.

Thanks much!

Bob

rsheehy@radford.edu

Can`t Log-In after installation.
I`m do all from

http://sourceforge.net/forum/forum.php?thread_id=1607758&forum_id=617260

but i see only one page: "Autorisation require"

I have the same problem, but I solve the problem! I have installed my wiki with the langugage "german" (de) and then it doesn't work!

You must write (for mediawiki with language de): $wgWhitelistRead = array('Hauptseite','Spezial:Userlogin','Spezial:Userlogout','Spezial:Search'); --> than it works !!!!!!!!!

--62.47.49.81 10:54, 10 February 2007 (UTC)

Add this to file LocalSettings.php
$wgWhitelistRead = array('Main Page','Special:Userlogin','Special:Userlogout','Special:Search'); $wgWhitelistEdit = array; $wgWhitelistExecute = array('Main Page','Special:Userlogin','Special:Userlogout','Special:Search');

actually...
...you may want to include the entire contents of LocalSettings.php.txt; it includes those three lines as well as some others without which you may get errors (I did). --Woozle 17:19, 28 February 2007 (UTC)

how to delete User Groups
Anybode explain how to delete User Groups added through Special:Userrights?


 * Answer
 * Just select the group without adding it in the Edit user groups section.

WikiMedia 1.9?
Has this been tested and used on a WikiMedia 1.9 installation? I have a freshly installed 1.9.1 WikiMedia site and can't get this extension to function. Thanks.

I testeted too and it doesn't work! There is an error! --62.47.49.81 10:48, 10 February 2007 (UTC)

I have MediaWiki 1.9 installed and used the groupwikibase manual patch 1.2. Seems to work fine. 64.180.182.215 02:05, 24 March 2007 (UTC)

Problem Diskussion/Article Pages!!
After installing the patch (with no problems), my wiki doesn't no the differences between: Article Diskussion:Article (show the same content, but it is different)

but when I go to edit, it shows the right content!! ....index.php?title=Hauptseite&action=edit ....index.php?title=Diskussion:Hauptseite&action=edit

examples: http://elearning.mat.univie.ac.at/elearnphysik/wiki/index.php?title=Diskussion:Hauptseite&action=edit http://elearning.mat.univie.ac.at/elearnphysik/wiki/index.php?title=Hauptseite&action=edit http://elearning.mat.univie.ac.at/elearnphysik/wiki/index.php/Hauptseite http://elearning.mat.univie.ac.at/elearnphysik/wiki/index.php/Diskussion:Hauptseite

Please help me!!

Thank you for the great extension!!!!

--62.47.49.81 11:08, 10 February 2007 (UTC)

Possible Answer

Can the authors of GroupWikiBase please explain the following, and add this to list for correction. In addition to having the same problem with Discussion/Article confusion as explained above, I also have an installation that extends Article class, (such as Class MyArticle extends Article). When using GroupWikiBase and Editing any of my extended articles, I get bizarre failures, such as Edit Conflicts when there were none.

After investigating, it appears the GroupWikiBase extension is overwriting $wgTitle->mArticleID. This doesn't seem too super. It is done in the following two places within the GroupWikiExt.php extension.

function userCanExt(&$titleObj, &$wgUser, $action, &$result) { ... $wgTitle->mArticleID = getPageID($titleObj); ... }

...

function getPermissionsExt(&$titleObj,$type,$action) { ... $wgTitle->mArticleID = getPageID($titleObj); ... }

Why does GroupWikiBase attempt to overwrite the mArticleID?

I have found if you comment out the two lines shown, the problems go away. However, I will guess they were originally put there for a reason. If I figure out why i'll add more info. --154.5.111.158 03:36, 26 March 2007 (UTC)

undefined function userCanExecuteExt
I am using the full-download version of GroupWikiBase (1.2), installed from scratch on an empty database.

After adding the requisite 3 lines to LocalSettings.php and logging in, I get this error message:


 * Fatal error: Call to undefined function userCanExecuteExt in /hsphere/local/home/hypertwi/sekrit.hypertwins.org/includes/SpecialPage.php on line 484

A quick search for that function name shows that it is defined in extensions/GroupWikiExt.php, so I added the following line to LocalSettings.php:


 * require_once('extensions/GroupWikiExt.php');

That removed the first error message and actually shows me a log-in page, but it starts with the following errors:


 * Warning: in_array [function.in-array</a>]: Wrong datatype for second argument in /hsphere/local/home/hypertwi/sekrit.hypertwins.org/extensions/GroupWikiExt.php on line 206


 * Warning: in_array [<a href='function.in-array'>function.in-array</a>]: Wrong datatype for second argument in /hsphere/local/home/hypertwi/sekrit.hypertwins.org/extensions/GroupWikiExt.php on line 220


 * Warning: in_array [<a href='function.in-array'>function.in-array</a>]: Wrong datatype for second argument in /hsphere/local/home/hypertwi/sekrit.hypertwins.org/extensions/GroupWikiExt.php on line 220

"line 220" is also the culprit in two more errors later on that page.

I looked at the lines in question, and determine that the culprits are variables called $wgGroupsAllowedCreateaccount and $wgAnonPermissions. I searched through the source code to see where they might be defined, and lo and behold I come across LocalSettings.php.txt, which says right at the beginning "APPEND EVERYTHING HERE TO YOUR LOCALSETTINGS.PHP".

Did that, and now the login screen seems happy. I'm going to make a note of this on some of the earlier comments where the answer was to just include 3 lines; if you include LocalSettings.php.txt, it includes those 3 lines as well. --Woozle 17:17, 28 February 2007 (UTC)

page permissions not editable
I figured this out immediately after posting, but I'll go ahead and document it because I had spent substantial time on it before that.

In order to edit permissions for a page:
 * Click the "protect" tab for the page whose permissions you want to edit
 * Add one or more groups or users to the ACL (left box)
 * Select (in the ACL) the individual group or user whose permissions you want to specify; this enables the checkboxes
 * Select whatever permissions you want applied by checking the appropriate checkboxes
 * (Optional: enter a brief explanation of the changes you made)
 * Press the "Confirm" button

security hole
Maybe there is an additional step I need to take, but a search will show me partial content for a protected page even when I am not logged in (and can't, for example, browse to the page itself). The summary for GroupWikiBase says "search does not return restricted pages", so I must have something not set up right.

Also... why are there no groups for "users not logged in" and "users logged in"? How would I grant certain permissions on certain pages only to logged-in users, without having to go through the intermediate stage of manually adding them to a group with the appropriate permissions?

--Woozle 19:13, 28 February 2007 (UTC)

Update: see, above. --Woozle 18:21, 20 March 2007 (UTC)
 * Answer
 * "Logged in users" and "Not logged in users" groups can be configured in LocalSettings.php. The search problem is probably a bug, however there are no active developers working on the project until May.

Hide a page
Anon- and LoggedIn-User should read MOST of the wiki-pages, therefore: $wgAnonPermissions = array('read',.....); $wgLoggedInPermissions = array('read',....); When I do this, I can not hide pages for anon- and loggedin-users anymore! anon- and logedin-users have no group and so I can not deny read-rights! Are there other options to do this ??? Thank you for your help! --80.109.6.153 10:26, 13 April 2007 (UTC)