Talk:GroupWikiBase

Hiding partial content from Search Results

Latest comment: 17 years ago2 comments2 people in discussion

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.

To do this, on /Includes/SpecialSearch.php, Replace the following codes in showHit function:

 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];

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

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


 $pat2 = '/(' . $terms . ")/i";
 $line = preg_replace( $pat2,
   "<span class='searchmatch'>\\1</span>", $line );

 $extract .= "<br /><small>{$lineno}: {$line}</small>\n";
 }

to the following:

 // 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;}

 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,
   "<span class='searchmatch'>\\1</span>", $line );

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

Ypae 23:23, 5 March 2007 (UTC)Reply

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)Reply

Automatically search custom namespaces if you are in matching groups

Latest comment: 17 years ago1 comment1 person in discussion

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:

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;
}

On /Includes/SpecialSearch.php, right before the following lines:

 $namespaces .= " <label><input type='checkbox' value=\"1\" name=\"" .
   "ns{$ns}\"{$checked} />{$name}</label>\n";

Add the following:

 // ypae Custom Namespace search automation Begin.
 global $wgUser,$wgExtraNamespaces;

 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 .= " <label><input type='checkbox' value=\"1\" name=\"" .
   "ns{$ns}\"{$checked} />{$name}</label>\n";

if you want to have different group prefix other than "wiki", you can find and replace 'wiki'. to whatever you want.

I hope that this helps. Ypae 19:21, 5 March 2007 (UTC)Reply

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

Latest comment: 17 years ago1 comment1 person in discussion

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."<BR>";
 //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)Reply

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.

Latest comment: 17 years ago1 comment1 person in discussion

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)Reply

Add this to file LocalSettings.php

Latest comment: 17 years ago1 comment1 person in discussion

$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)Reply

how to delete User Groups

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

WikiMedia 1.9?

Latest comment: 17 years ago4 comments3 people in discussion

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)Reply

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)Reply

Loaded up manual 1.2 and i dont see the page on wiki 1.10.1 ?? Any Help --142.47.130.37 18:07, 21 September 2007 (UTC)Reply

Just checked-out 1.8.5 and it works with that. Any fixes for latest MW release?--142.47.130.37 18:07, 21 September 2007 (UTC)Reply

Problem Diskussion/Article Pages!!

Latest comment: 17 years ago4 comments3 people in discussion

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)Reply

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)Reply

I have used your fix for this. It certainly works. Thank you. Any update on why those two lines were there in the first place? I worry this has broken something else. --Pmcclure 15:19, 19 October 2007 (UTC)Reply

I have discovered there is no way to set group permissions on talk pages. It looks like you can set them, but they don't stick on the talk pages. Now I am wondering if these lines above which I commented out were somehow related to extending the same permissions on articles to their associated talk pages (a failed attempt at this, that is). Not sure. Regardless, I need to find a way to either extend the same permissions to talk pages OR to at least have the ability to set talk page permissions independently. Either way would be ok. I'll post back here if I resolve this. --Pmcclure 03:25, 26 October 2007 (UTC)Reply

undefined function userCanExecuteExt()

Latest comment: 17 years ago1 comment1 person in discussion

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() [<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 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

"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)Reply

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

Latest comment: 17 years ago2 comments1 person in discussion

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)Reply

Update: see #Hiding partial content from Search Results, above. --Woozle 18:21, 20 March 2007 (UTC)Reply

Hide a page

Latest comment: 17 years ago1 comment1 person in discussion

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)Reply

IsAllowed issue

Latest comment: 17 years ago1 comment1 person in discussion

Another technical note / issue that will probably need to be fixed. GroupWikiBase modifications edit the IsAllowed method in User class which isn't too much of an issue, except it grabs global $wgTitle and uses it. This isn't super, because User::IsAllowed('permission') probably should not be assuming a title. 76.22.61.194 14:42, 12 May 2007 (UTC)Reply

In USER.PHP:

function isAllowed($action='') {
	/*if ( $action === '' )
		// In the spirit of DWIM
		return true;

	$this->loadFromDatabase();
	return in_array( $action , $this->mRights ); */
   //groupwiki mod begin
   $result = null;
   global $wgUser;
   global $wgTitle;

   wfRunHooks( 'userCan', array( &$wgTitle, &$wgUser, $action, &$result ) );
   return $result;
   //groupwiki mod end

I cannot login after instalation

I cannot login after i install the mediawikibase when I click at login the page just refresh! I cannot create an account! I did all setup needs. Please, Anyone use that mediawikibase to help me? thanks hugosousajr@gmail.com

Follow up from shashi - Hi Hugo, can you please let ne know if you still have this issue, how did you resolve this. I'm having the same issue after installting this extension on mediawiki 1.17. When i try to login , it just stays there, won't get redirected to the credential page. Can you please email me or provide me a response on thi. Shashi.kum78@yahoo.com.

Thanks in advance.

Protection Page

i've got only two checkboxes. One for edit and one for move but on the picture of GroupWikis Protection page there are many more. Is somebody so friendly to help me please :(

Image thumbs don't work

I get full size images instead of thumbs after installing GroupWiki_Base or after patching MediaWiki. Any clues?

unexpected T_NAMESPACE, expecting T_STRING

Using php 5.3.0 it seems the word Namespace is a "keyword" Mediawiki is using MWNamespace instead

Add topic