Last modified: 2011-03-13 18:05:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4106 - Patch for handling group permissions
Patch for handling group permissions
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.5.x
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://iridia.ulb.ac.be/~acampo/softw...
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-28 22:34 UTC by Alexandre Campo
Modified: 2011-03-13 18:05 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
the patch to handle group permissions (114.45 KB, patch)
2005-11-28 22:39 UTC, Alexandre Campo
Details

Description Alexandre Campo 2005-11-28 22:34:46 UTC
The purpose of the patch is to allow a page to have restrictions on groups, and
prevent any user that does 
not belong to the right group from viewing or reading that page.

The patch adds a tab called 'restrict', available to users who can
'setpagegroup'. Clicking on this tab gives access
to a field so the user can modify himself (no graphical tools) the field
'page_restrictions' of a given page.

Combined to an extended definition of the variable $wgGroupPermissions, one can
add more groups.

I had to modify the method userCan and userCanRead of Title.php to make the
mechanism effective.

For instance and to give a concrete example : imagine you have physicists and
chemists using the same wiki.
For any reason, physicists must not access the pages of chemists and vice-versa.
The sysop can define two groups, 
ph and ch for instance. Then he puts each chemist user in the group ch and
physicists in the group ph. This is done
in the LocalSettings.php, altering the array $wgGroupPermissions. Now the pages
can be assigned a restriction to
ch or ph group for read or edit actions, through the 'restrict' tab.  

This patch is functionnal, but not very secure (direct access to the database,
through a text field in html, but limited to sysops)
In addition the wgGroupPermissions array must definitely be encoded in the
database, and have some nice html pages
to modify it.
Comment 1 Rob Church 2005-11-28 22:37:00 UTC
I wish people would read, now and again, what is written all over...
Comment 2 Alexandre Campo 2005-11-28 22:39:22 UTC
Created attachment 1111 [details]
the patch to handle group permissions
Comment 3 Brion Vibber 2006-02-03 04:14:31 UTC
This whole type of thing is unsafe to tack onto the MediaWiki framework, which has many many 
ways of providing access to the contents of any page.

Anyone with an actual requirement to prevent groups from being able to read each others' 
content should either *not* use MediaWiki, and use some other software which can provide what 
they require, or should install separate wiki instances for each group.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links