Help talk:User rights

From Meta, a Wikimedia project coordination wiki

How do I get the user's ID[edit]

You wrote:

 The user rights are in a table called user_groups with two fields called ug_user and ug_group. 
 There must be one row inserted for each group the user belongs to. You must know the user 
 id number of the user from the users table. This sql query should do the trick. In the example 
 below substitute 1 with the user ID number from the users table.

How do I get in my private wiki the user's IDs? I created somme accounts and tried in the database

 SELECT * FROM wikiuser;

But I only got crypted outputs, neither the users' accounts nor the IDs could I detect.

Thanks,

Andreas Alef ( andreas.alef@web.de )

Restriction for visitors not seeming to work[edit]

Hello I have pasted this code from this help guide into my localsettingsfile and changed createpage and createtalk to false since I want to stop visitors from creating pages. So it now reads:

$wgGroupPermissions = array();

// Implicit group for all visitors

$wgGroupPermissions['*' ]['createaccount'] = true;
$wgGroupPermissions['*' ]['read'] = true;
$wgGroupPermissions['*' ]['edit'] = true;
$wgGroupPermissions['*' ]['createpage'] = false;
$wgGroupPermissions['*' ]['createtalk'] = false;

Thing is it doesnt seem to work! I thought the lines of code were doing nothing but then I removed the $wgGroupPermissions['*' ]['read'] = true; line and that stopped all visitors from seeing any page so fine the code was doing something.

So why can visitors still create talk and regular pages even though I have set it to false with this code?

I have also noticed that when this code is in effect protected pages seem to go 'stealth', that is even when logged in as sysop the unprotect, edit and other tabs totally disappear which I find odd. Whats going on?

Thanks

Cyclotron 15:38, 13 February 2007 (UTC)[reply]

Question: Can user restrict her page?[edit]

With this schema, Can user restrict her page, so NOBODY (except himself) can read it ??? i.e. User1 create a page , and sets it to NOBODY can read it. or he wants that User2 and User3 can read it, but everyone could not read it. --Coff

No, this doesn't affect anything but what are now considered "sysop", "bureaucrat", and "developer" powers. All pages will be viewable by anyone unless it is changed in LocalSettings.php or the permission level for "read" is changed, in which case it affects all pages equally.

file to this page not functional[edit]

It should be noted that the file to this page is in 1.4beta6, but it is not functional (gives DB error: "1146: Table 'wikidb.group' doesn't exist (localhost)"). --Astronouth7303 23:48, 14 Feb 2005 (UTC)

Namespace restrictions for user groups / A Dream[edit]

will there be namespace or even page restrictions to usergroups? For example: a user group can read/write all pages in namespace A, but can't do anything to, or even see pages from, namespace B?


It would really be wonderful to be able to set access controls by group for various namespaces, categories, or pages. This would make MediaWiki a viable option for intranets and a simpler, easier to use, choice as compared with TWiki.

There have been different initiatives to develop such thing: see Page access restriction with MediaWiki and Hidden pages. I fully agree that their implementation in the main development branch (instead of having them as "patches") would help make MediaWiki a viable option for intranets, as a "ready-to-use" solution (with tools like TWiki, configuration of plugins is needed).
Not to forget that the wide user base, as well as the strength of Wikimedia, are incentives to think that MediaWiki won't die in short-medium term (or, if it is replaced by something better, that the tools to convert the database will be available). --193.56.40.253 08:48, 3 Jun 2005 (UTC)


Split levels[edit]

delete should be split into delete (pages) and deleteimg (images). undelete should be split into viewdel and undelete. Guanaco 03:41, 6 Dec 2004 (UTC)

In general I'm with the people who want to split "undelete" (as above), "delete" (as above), "protect" (into protect and edit-protected), etc. Not that I feel we will want to make a practise of splitting them apart (especially not right away), but rather because I think that if we're going to change this part of the interface, we should do it all at once, and not dribble additions on later. I would assume that these changes are only an incremental amount of work for a developer (now that admin has already been split into a large number of different capabilities) so I don't feel too bad about requesting "just one more small change"! Jnc 13:55, 10 Dec 2004 (UTC)

Can users protect the pages they start themselves?[edit]

I hope the new version will have the option to allow registered users to protect pages they start themselves, so only themselves and SysOPs can edit them. Also, i think the User:<user'sname> page and everything underneath (ex: User:John/myskin.css) should only be editable by the user himself/herself or the SysOP.

If this is already do-able, please tell me how.

Add an extra tag for user rights[edit]

It could be very useful to add an extra tag such as [Restrict <type>:<users>|<groups]

This could be used in a similar way to the cateory tag.

The tag behaviour when used in various places would be:

  • On a page it will restrict access to that page to do the specified type of action to the listed users or groups.
  • On a category page it will restrict access to 'all' pages in the category to do the specified type of action to the listed users or groups, without overriding specific page restrinctions.

The types could be similar to those on the main page, i.e.:

  • read
  • edit
  • protect
  • etc.

194.129.249.241 08:38, 25 Apr 2005 (UTC)

I agree. I require different levels of read and write permission for certain pages according to the employees/contractors role. Have you had any feedback? For example I want people with "Permission level 1" to be able to view pages set to level 1, and people with "Permission level 2" to be able to view level 2 content, as well as level 1.... clear? Charlie Evatt

Terminology[edit]

I think this is a really cool set of features. One small concern I have is regarding terminology. This appears to be a w:Role-Based Access Control system, but with different terminology. See Role Based Access Controls at NIST for the gory explanation.

Here's what I see as the difference:

Current MediaWiki 1.5 RBAC
Level Permission
User Group Role

Is my assessment of the situation correct? If so, it'd be nice to move toward using more standard terminology. It's not something worth slowing down a 1.5 release, but it'd be good to eventually align this. -- RobLa 00:55, 31 May 2005 (UTC)[reply]

Implement different access levels?[edit]

I need to implement two groups of users: those who can merely read, and those who can also edit. However, it seems the rights of the 'user' group overrule everything: if I put the users who should edit in an "edit" group, and restrict user access, nobody can edit. If I put the users who sould be restricted in a "restrict" group and allow user editing, everybody can edit, and since I can't remove anyone from the user group, access levels seem to be impossible. Or am I wrong, here?

At least let me see the login page...[edit]

I need to restrict read access to logged in users only. However, when I do that, nobody is allowed to view the login page anymore...can I set single pages "read by all" or something?

Yes. With the following in your LocalSettings.php file, annonymous users will be able to read only the Main Page and the Login page. If you want to allow anyone to create an account, then just change the first false to true.

 # Allow anyone to see the Main Page and the login page
 $wgWhitelistRead = array( "Main Page", "Special:Userlogin" );
 # Don't let anonymous users do anything!
 $wgGroupPermissions['*'    ]['createaccount']   = false;
 $wgGroupPermissions['*'    ]['read']            = false;
 $wgGroupPermissions['*'    ]['edit']            = false;

If you have prevented anonymous creation of account and want to create another account, simply login as a sysop and use the special page Special:Userlogin (Listed as Create an account or log in in the list of special pages) to add the new user account. --Jcarroll 05:23, 30 October 2005 (UTC)[reply]

This does not work under some circumstances and there is no solution yet.

userrights includes sysop and bureaucrat?[edit]

If I allow users to set userrights this also allows them to make other users sysop or bureaucrat. Can I restrict the list of rights that users can set so as not to include sysop and bureaucrat?

One way to implement this restriction which I think would scale appropriately is to make the userrights permission only allow somone to give permissions which they themselves already have. Thus if you give the userrights permission to someone who only has patrol and block then they can only give patrol and block to someone else, not turn someone else into a SysOp.

--Eric Myers 18:43, 23 June 2006 (UTC)

How do I set these directly in the database?[edit]

I don't have an admin so I'll need to set them directly in the database. How do I do it? 1.4 had the user_rights table with the ur_rights field, how do I do that in 1.5?

Seems like you just add pairs of userid and group name into the user_groups table.
Example: INSERT INTO user_groups (ug_user, ug_group) VALUES (1, 'sysop');
Unlike 1.4 this isn't a comma separated list. For more groups you insert more rows.

Introduce a "viewdeleted" right?[edit]

On the Dutch wikipedia, there is a "sysop observer" who is not a sysop, but is a member of the sysop's mailing list. There is currently a discussion going on of giving this observer sysop rights as well, so he can view the content of the deleted pages (not that there is any particular distrust of the sysops, but it's nice to have checks and balances). I was thinking this could also be implemented by having a "viewdeleted" right, which would mean the user can view deleted content (not just the history entries and comments, as it is now), but not undelete anything. – gpvos (talk) 23:24, 7 October 2005 (UTC)

Read/Edit conflict for users not signed in[edit]

I'm trying to make a private wiki for my organization, but also allow certain pages to be viewed by the public. This means I want to allow read/edit priviledges for logged in users, but only read priviledges for people belonging to the '*' group.

The code I added to LocalSettings.php is as follows:

 $wgWhitelistRead = array ("Main Page", "Special:Userlogin", "Wikipedia:Help", "FAQ");
 $wgGroupPermissions['*'    ]['createaccount']   = false;
 $wgGroupPermissions['*'    ]['read']            = false;
 $wgGroupPermissions['*'    ]['edit']            = false;
 $wgGroupPermissions['user' ]['createaccount']   = false;
 $wgGroupPermissions['user' ]['read']            = true;
 $wgGroupPermissions['user' ]['edit']            = true;

Only the four pages specified are accessible to the public, but it is also possible to edit those pages. Is there anything I can do to prevent those pages from being edited by non-logged-in users?

  • As sysop, Protect -> Block unregistered users only.

Other pages on $wgWhiteListRead[edit]

I have found that in order to stop errors being generated during page load you also need to include the default CSS and Javascript pages (which are pulled from the wiki like any other pages). Therefore, if the default skin for your wiki is Monobook, I would suggest a minimum set of pages as follows:

$wgWhitelistRead = array("Main Page", "Special:Userlogin", "-", "MediaWiki:Monobook.css");	

-- HappyDog 18:59, 19 October 2005 (UTC)[reply]

What if you don't want "Main Page" on this list? If you do this, it says the usual message, but the usual message doesn't make sense: "You must login to view other pages. Return to Main Page.". Also the redirect after a few seconds brings you back to the same message (and goes on re-requesting forever) -- Harry Wood 14:32, 18 July 2006 (UTC)[reply]
I created a dummy (public) Main page as workaround. The real Main Page I keep disclosed for the public, only to be viewed by loggedin users. 84.86.245.243 23:42, 5 August 2006 (UTC)[reply]

Disable edits, but allow discussion.[edit]

I am setting up a Wiki so that I can keeps notes on stories I'm writing. I have followed instructions so only the Editor group I created is able to edit pages, and general users are not allowed. However turning off Edit for a group also prevents them from discussing the page in question as well.

Is there a way to prevent a group from being able to edit articles, but still add to the discussion pages?

I assume this would be covered in the Namespace permissions suggested above, deny edit for *: while allowing it for Talk: or something similar to that. If that's the case, put in my vote for te namespace permissions.


--Wrongdave 21:35, 9 July 2006 (UTC)Greater flexibility in allowing or restricting editing of Talk/Discussion pages separately from the main pages seems to be a popular request (and a logical one). There is a hack described on Help:User_rights that allows editing of talk pages for all users (logged in or not)for version 1.6 and there was another hack for older versions that basically accomplished the same thing (the older hack doesn't work in 1.6). I too am interested in handling permissions for editing Talk pages by user group (rather than just allowing anyone to edit talk pages per the hacks).[reply]

Restricting editing or creation of headlines[edit]

Exists a way to restrict editing or creation of headlines?

Thanks in adv, helio (dot)ricardo (at) gmail (dot) com

Allow user to delete "his" uploads?[edit]

Is there a way to grant a user the right to delete his own uploaded file (not a general deletion-right!)? Maybe very useful in case of a mistake that he uploaded a private file instead of his intended image. 134.76.81.25 14:46, 16 February 2006 (UTC)[reply]

BlacklistRead vs. WhitelistRead[edit]

Instead of a whitelist limiting user access to a small set of pages, what wikimedia really needs is a blacklist. Thus limiting access to small set of pages and not restricting the others, seems to be most common case. At least it is much more in the spirit of openess than whitelisting.
128.243.220.42 17:47, 31 March 2006 (UTC)[reply]

That makes a lot of sense.. I agree with that too Karthikraman 11:06, 11 April 2006 (UTC)[reply]
This is exactly what I just came here looking for. I'm sad to see it's not implemented, and join the chorus in favour! -203.12.172.254 05:50, 27 April 2006 (UTC)[reply]

Restricting access to a namespace[edit]

Is it possible to restrict access to non logged in users to all articles in a namespace? Basically something like a regular expression Black List.... All pages with title "Internal:*" should be out of the White List. Is there a simple way to do this in mediawiki 1.6.3?

Karthikraman 11:06, 11 April 2006 (UTC)[reply]

Where in code[edit]

Where exactly in the code is it determined whether the user can perform the current action? Thanks. Bmearns 23:52, 15 May 2006 (UTC)[reply]

includes/skinTemplate.php look arround the line 796

wgGroupPermissions for action edit doesn't work[edit]

I added to the LocalSettings.php the following lines:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user' ]['edit'] = false;

The first one works perfectyl, the second line doesn't have any effect. anyone knows why?

How are you testing it, with your own account? Because most likely your account is an admin, or some similar position of authority, so "user" doesn't cover you. If that's the case, just create a new test account that only has user rights (should be the default for new accounts), and try with that. If that's the problem, I'm not usre what is, sorry. Bmearns 12:10, 2 June 2006 (UTC)[reply]

I'm having the same problem. I'm trying to create two groups: folks who can just read and folks who can edit. I have the following lines in my LocalSettings.php file:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['mdreader']['edit'] = false;
$wgGroupPermissions['mdediter']['edit'] = true;

When I assign a test user to the group mdreader it still can edit pages. Shaineb, 18 June 2006


Get the same trouble[edit]

I have the same situation like you. I create a new group called 'group4'. Then I add a test account to this group. Here is the code in LocalSettings.php :

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['group4']['read'] = true;
$wgGroupPermissions['group4']['edit'] = false;

I add the user "Sarah" to group4 but she still can edit pages. I don't know why. Can any body explan for me ? Thank in advance.

  • My email : thanlannau@yahoo.com
  • If replying via email, please wirte the title : User rights problem.

Thank you. Nov 27th, 2006

Allowing only the logged-in users to view the history tabs and the history entries[edit]

Hi people. I'm sure this sounds very thick of me, but I would like to do the following thing but I have no idea how to do it. I want to allow only the logged-in users to view the history tab. Of course, I also wish to restrict access to the history entries to everyone except the logged-in users. Maybe this goes hand-in-hand with my first request. Thank you good people. --- Mary Jane 02:34 (UTC)


Block User Registration and Block People From Editing[edit]

Thank you for all this, it blocks anyone from registering an account plus it lets restrict people from viewing articles ulness they are logged in. I have been looking for this for a while.

Restrict read access for blocked users[edit]

I have a wiki (running v1.6.6) that's set up to disallow anonymous read access. I did this the typical way, by adding the following lines to my LocalSettings.php

$wgGroupPermissions['*'    ]['createaccount']   = false;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgWhitelistRead = array ("Special:Userlogin", "Wikipedia:Help");

My question is: is it possible to restrict read access for registered users who have had their accounts blocked? I've tried two methods of accomplishing this and neither have met me with much success.

The first thing I tried to do was creating a new group called "blocked", and adding the blocked user to this group. I defined this new group with the following line in LocalSettings.php:

$wgGroupPermissions['blocked']['read']          = false;

This didn't work. After pondering it a bit, I figured that MediaWiki probably grants a user the least restrictive set of abilities dictated by their groups. Despite the fact that BlockedUser is a member of the "blocked" group, they're still also considered a normal registered user. And since normal registered users are allowed to view pages, BlockedUser is too.

My next idea was to remove BlockedUser from the "user" group. I got this idea by examining the output of the "Permissions" extension. It didn't work. After examining the user_groups table in the database, I realized that there isn't really any such group as "user". So, at this point I'm a bit stumped. Is there any way to prevent blocked users from viewing pages in a read-access restricted wiki?

Different groups with different rights[edit]

I would like to create different groups with different rights, but where I can change these? I read the text above many times, the discribtion, but I hadn't understand it until now. Another question is: One group should become a additional right...to edit one page (for example: Article of the Week). All other shouldn't be able to edit this page. Can you help me, please?!I work with the MediaWiki Software 1.8.2
Tomsen 20:20, 4 December 2006 (UTC) (PS: I also posted at the article page)[reply]

I answered my first question already. Please answer the second questions as quickly as possible. Tomsen 19:37, 5 December 2006 (UTC)[reply]

++++

I need something similar. I need to restrict user access based on where they are on the org chart. Execs would be able to see everything. Sales people only the public and Marketing parts of the wiki. Ops only the public and Production parts of the wiki... etc. etc. Has anyone built a tool to implement this easily instead of the hacks to the php code and in some cases the database? 70.252.80.63 05:11, 1 February 2007 (UTC)[reply]

++++

Please forgive a newbie question. I would like to restrict edit access to users with confirmed emails of a particular domain (e.g. @institution.edu). Ideally, I would like to be able to restrict edit access to a particular (large) list of people (could use a system call to determine if an individual is on that list, I suppose). Is this doable? Advice welcome. Binsted 07:39, 21 March 2007 (UTC)[reply]

what usergroup is default?[edit]

Is the 'user' usergroup the default for logged in users? is it possible to specify a different group somewhere? or possibly rename it?

Allow HTML - Image click behaviour[edit]

I want to allow my sysops to use HTML (eg. clicking on an image redirects to a article not to the image). What I've to do? -- annon

There's a (somewhat ugly) workaround for this particular problem. Have a look at Template:Click and the way it used on mediawiki.org Main Page -- Harry Wood 11:43, 26 January 2007 (UTC)[reply]


grant read access to certain usergroup[edit]

sorry for a newbie question, how can i grant read access to certain pages to certain users/usergroups? thanks

Any way to restrict editing article except the user who created it ?[edit]

Is there any way to do so ? via plugin , extension or any other way ?

Restriction on * group also restricts create account[edit]

I have implemented the read restrictions to my website for not registered users, however when a person registers himself, the confirmation email cannot activate the email account.

Example: 1. I have the following code in localsettings.php

$wgGroupPermissions['*' ]['createaccount'] = true; $wgWhitelistRead = array( "Hoofdpagina", "Main_Page", "Special:Userlogin", "Special:Confirmemail/", "-", "MediaWiki:Monobook.css" ); $wgGroupPermissions['*']['read'] = false;

2. If a new user creates an account, he will get an confirmation email where he needs to click on a hyperlink to activate his account. however, when doing this, mediawiki will answer that he needs to login before this link works.

Quite logic to me, but how can I allow permissions for activating the account?

Thanks: Ferry Spaan (ferry true@ gmail.com (remove spaces))

creating groups in wikis[edit]

I've been a wiki user for years, and a few years ago I set up and administered wikis for my department. Now I've been put in charge of running a new, public wiki. The Systems people have installed it --

  • MediaWiki 1.12.0
  • PHP 5.2.6-1+lenny3 (apache2handler)
  • MySQL 5.0.51a-24+lenny1

-- and made me a bureaucrat and a sysop, and now I'm trying to come up to speed. I'm working with the MediaWiki Handbook and LocalSettings.php, but there's a lot that I can't find.

Right now my question is: How do I create more groups? This wiki is meant to be world-readable, but people will have to request authorization to write to it, and there are to be separate sections with separate write authorization. I thought I'd be able to do that with groups and namespaces -- group A can write to namespace A, group B to namespace B, ... -- but all I can find is

You can add users to these groups: bot, sysop and bureaucrat.
You can remove users from these groups: bot, sysop and bureaucrat.

I can't find word one about creating new groups, even though I see numerous groups on this wiki here.

Is it doable? Is there a hole in the documentation? Do I need to ask our Systems folks to do something?

Thnidu 23:13, 24 June 2009 (UTC)[reply]