Hi,
We have setup Mediawiki within our University and have a fair understanding of it. Hoever, we failed to test the block feature and we discovered this after setting it up and starting to use it :(
Block seems to clock the username from posting but it does not block the user from logging in. Has there been any work to either block logins for blocked accounts or add an enabled flag in the user table?
Although wikis should be open communities, we use it for internal documentation and when an employee leaves (or student drop a course etc), we would like to be able to delete the or block the account from gaining read access. I am willing to work on this code if no one has done so already but want the efforts to be put into the main source so I dont have to do it over and over each time there is an upgrade.
Has anyone done this/started this/talked about this?
Dion Rowney U of S
On 8/29/06, Dion Rowney dion_rowney@hotmail.com wrote:
Hi,
We have setup Mediawiki within our University and have a fair understanding of it. Hoever, we failed to test the block feature and we discovered this after setting it up and starting to use it :(
Block seems to clock the username from posting but it does not block the user from logging in. Has there been any work to either block logins for blocked accounts or add an enabled flag in the user table?
Although wikis should be open communities, we use it for internal documentation and when an employee leaves (or student drop a course etc), we would like to be able to delete the or block the account from gaining read access. I am willing to work on this code if no one has done so already but want the efforts to be put into the main source so I dont have to do it over and over each time there is an upgrade.
Has anyone done this/started this/talked about this?
This bug has status "Resolved (wontfix)"
Am I correct in that it Its also seems to elude to trying to block users from certain sections, The entire wiki and loging completion?
Dion
From: Simetrical Simetrical+wikitech@gmail.com Reply-To: Wikimedia developers wikitech-l@wikimedia.org To: "Wikimedia developers" wikitech-l@wikimedia.org Subject: Re: [Wikitech-l] Disabling users Date: Tue, 29 Aug 2006 14:09:10 -0400
On 8/29/06, Dion Rowney dion_rowney@hotmail.com wrote:
Hi,
We have setup Mediawiki within our University and have a fair
understanding
of it. Hoever, we failed to test the block feature and we discovered
this
after setting it up and starting to use it :(
Block seems to clock the username from posting but it does not block the user from logging in. Has there been any work to either block logins
for
blocked accounts or add an enabled flag in the user table?
Although wikis should be open communities, we use it for internal documentation and when an employee leaves (or student drop a course
etc), we
would like to be able to delete the or block the account from gaining
read
access. I am willing to work on this code if no one has done so already
but
want the efforts to be put into the main source so I dont have to do it
over
and over each time there is an upgrade.
Has anyone done this/started this/talked about this?
See http://bugzilla.wikimedia.org/show_bug.cgi?id=1924. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 29/08/06, Dion Rowney dion_rowney@hotmail.com wrote:
This bug has status "Resolved (wontfix)"
Am I correct in that it Its also seems to elude to trying to block users from certain sections, The entire wiki and loging completion?
I don't think that was the bug that was supposed to be referenced. I might be wrong, but going on what the original poster's email said, I interpreted that as more of a "lock out accounts and hide them" job, which would come under http://bugzilla.wikimedia.org/show_bug.cgi?id=6397.
The referenced bug is a long standing feature request that we don't have plans to implement, owing to the fact that it contradicts a lot of the "ethos" of MediaWiki; its purpose and concept.
Rob Church
Have you tried:
Create a new group "readers", with "read" userright. Disable "read" rights for "users" group. Put your open content in the $wgWhitelistRead variable (login, main pages, etc); make sure anything sensisitve isn't in $wgWhitelistRead. To "activate" a new account, a burecrat has to add them to group "readers". To "deactivate" a new account, a burecrat removes them from group "readers".
See: http://meta.wikimedia.org/wiki/Help:User_rights LocalSettings.php includes/DefaultSettings.php
I haven't tested this quite yet, but was going to this week for an internal corporate MediaWiki I'm running.
If it doesn't work, let me know, so I can figure something else out. 8-)
Thank you so much. Thats work perfectly. Saved me a huge amount of time. We see only one drawback which should be easy enough to fix. When a user logs in, if they dont have "reader" access they get an error message saying "Login Required." We plan to override the message and say "Access Denied."
Regards!
Dion
From: "George Herbert" george.herbert@gmail.com Reply-To: Wikimedia developers wikitech-l@wikimedia.org To: "Wikimedia developers" wikitech-l@wikimedia.org Subject: Re: [Wikitech-l] Disabling users Date: Tue, 29 Aug 2006 14:47:15 -0700
Have you tried:
Create a new group "readers", with "read" userright. Disable "read" rights for "users" group. Put your open content in the $wgWhitelistRead variable (login, main pages, etc); make sure anything sensisitve isn't in $wgWhitelistRead. To "activate" a new account, a burecrat has to add them to group "readers". To "deactivate" a new account, a burecrat removes them from group "readers".
See: http://meta.wikimedia.org/wiki/Help:User_rights LocalSettings.php includes/DefaultSettings.php
I haven't tested this quite yet, but was going to this week for an internal corporate MediaWiki I'm running.
If it doesn't work, let me know, so I can figure something else out. 8-)
-- -george william herbert george.herbert@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Dion Rowney wrote:
Thank you so much. Thats work perfectly. Saved me a huge amount of time. We see only one drawback which should be easy enough to fix. When a user logs in, if they dont have "reader" access they get an error message saying "Login Required." We plan to override the message and say "Access Denied."
Regards!
Dion
Try modifiying [[MediaWiki:Loginreqtitle]] and [[MediaWiki:Loginreqtext]].
On Tue, Aug 29, 2006 at 10:18:12PM +0100, Rob Church wrote:
The referenced bug is a long standing feature request that we don't have plans to implement, owing to the fact that it contradicts a lot of the "ethos" of MediaWiki; its purpose and concept.
Sure.
Just like groups. And read-protection by groups. :-)
Cheers, -- jra
On 30/08/06, Jay R. Ashworth jra@baylink.com wrote:
On Tue, Aug 29, 2006 at 10:18:12PM +0100, Rob Church wrote:
The referenced bug is a long standing feature request that we don't have plans to implement, owing to the fact that it contradicts a lot of the "ethos" of MediaWiki; its purpose and concept.
Sure.
Just like groups. And read-protection by groups. :-)
Groups became a necessary evil. Read protection in MediaWiki is limited in implementation, which is a Good Thing, in my opinion.
People often seem to confuse MediaWiki with a magic solve-all for document management. While the platform is popular, quite mature and secure, and extremely extensible, and while MediaWiki is a pretty damn good collaborative editing application, it is subject to an enormous amount of abuse.
You have a pot of screws and a hammer. Purchase a screwdriver.
Rob Church
On 8/29/06, Rob Church robchur@gmail.com wrote:
On 30/08/06, Jay R. Ashworth jra@baylink.com wrote:
On Tue, Aug 29, 2006 at 10:18:12PM +0100, Rob Church wrote:
The referenced bug is a long standing feature request that we don't have plans to implement, owing to the fact that it contradicts a lot of the "ethos" of MediaWiki; its purpose and concept.
Sure.
Just like groups. And read-protection by groups. :-)
Groups became a necessary evil. Read protection in MediaWiki is limited in implementation, which is a Good Thing, in my opinion.
People often seem to confuse MediaWiki with a magic solve-all for document management. While the platform is popular, quite mature and secure, and extremely extensible, and while MediaWiki is a pretty damn good collaborative editing application, it is subject to an enormous amount of abuse.
You have a pot of screws and a hammer. Purchase a screwdriver.
Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
I have a real document management system. Several, in fact.
I also have a Wiki at (place I contract at) Work (Twiki), and at (contracting company I work for) Work (MediaWiki, in deployment now).
In both of those cases, the ability to ensure that non-employees aren't using the collaboration tools (Wiki, document management software, internal websites, internal sysadmin tools) is not only good business sense, but is at one of those locations a Sarbanes-Oxley compliance audit control.
Wikis are just as useful in environments where complete freedom of data access is not acceptable from a business standpoint. The employee community may be smaller than "everyone in the world", but the type and quality of interaction within the community can be helped greatly by Wikis and other modern internet collaboration.
"All information should be free!" likely does not extend as far as "...including your 401K manager's internal security data and all your health records", even for die-hard info-libertarians.
Some of these environments will benefit from Wikis; many of them will require additional access control. It's unreasonable to expect that MediaWiki would never find itself installed in such a situation.
On Tue, Aug 29, 2006 at 09:12:47PM -0700, George Herbert wrote:
You have a pot of screws and a hammer. Purchase a screwdriver.
I have a real document management system. Several, in fact.
I also have a Wiki at (place I contract at) Work (Twiki), and at (contracting company I work for) Work (MediaWiki, in deployment now).
In both of those cases, the ability to ensure that non-employees aren't using the collaboration tools (Wiki, document management software, internal websites, internal sysadmin tools) is not only good business sense, but is at one of those locations a Sarbanes-Oxley compliance audit control.
Wikis are just as useful in environments where complete freedom of data access is not acceptable from a business standpoint. The employee community may be smaller than "everyone in the world", but the type and quality of interaction within the community can be helped greatly by Wikis and other modern internet collaboration.
"All information should be free!" likely does not extend as far as "...including your 401K manager's internal security data and all your health records", even for die-hard info-libertarians.
Some of these environments will benefit from Wikis; many of them will require additional access control. It's unreasonable to expect that MediaWiki would never find itself installed in such a situation.
You're missing his point, though, George:
MediaWiki happily doesn't claim to provide those features, so if you spec it into those environments, *you've* screwed up. You're welcome to patch it to do anything you like, or pay someone else to, though.
If MediaWiki doesn't fill your needs, and you can't patch it to do so, you're welcome to use something else; Tim and brion won't be offended.
That said, see my other reply.
Cheers, -- jra
On Tue, Aug 29, 2006 at 09:12:47PM -0700, George Herbert wrote:
You have a pot of screws and a hammer. Purchase a screwdriver.
I have a real document management system. Several, in fact.
[..Snip..]
Some of these environments will benefit from Wikis; many of them will require additional access control. It's unreasonable to expect that MediaWiki would never find itself installed in such a situation.
You're missing his point, though, George:
MediaWiki happily doesn't claim to provide those features, so if you spec it into those environments, *you've* screwed up. You're welcome to patch it to do anything you like, or pay someone else to, though.
If MediaWiki doesn't fill your needs, and you can't patch it to do so, you're welcome to use something else; Tim and brion won't be offended.
I think George's point was that there are many intranet environments (not just his) where easier access-control would be a useful addition to the software.
One need only look at bugzilla, and the access-control request bugs, to verify this as being correct.
That said, this behaviour (e.g. restricting read access) is not desired on an open collaborative site like the Wikipedia.
Basically there's a tension between the real-world ways in which people want to use MediaWiki the software "product", and the primary raison d'etre of MediaWiki as an open-to-everyone collaborative platform.
The more interesting question is: If people can find a way of adding this type of functionality to the default install (but disabling it by default) so that it doesn't impact you, should it be added?
On the plus side, it'd most likely lead to more deployments of the software, and hence more people familiar with the syntax, and more people familiar with wikis in general, and what people get used to at work they tend to use at home too (with potential positive impact). On the negative side, maybe it's seen as complicating the software, and endorsing a feature that's opposed to the fundamental aim of open knowledge.
All the best, Nick.
"Nick Jenkins" nickpj@gmail.com wrote in message news:NABBJGECPILFNLFEAPIKOEINIMAA.nickpj@gmail.com...
If MediaWiki doesn't fill your needs, and you can't patch it to do so, you're welcome to use something else; Tim and brion won't be offended.
[SNIP]
Basically there's a tension between the real-world ways in which people
want to use MediaWiki the software "product", and the
primary raison d'etre of MediaWiki as an open-to-everyone collaborative
platform.
The more interesting question is: If people can find a way of adding this
type of functionality to the default install (but
disabling it by default) so that it doesn't impact you, should it be
added?
On the plus side, it'd most likely lead to more deployments of the
software, and hence more people familiar with the syntax, and
more people familiar with wikis in general, and what people get used to at
work they tend to use at home too (with potential
positive impact). On the negative side, maybe it's seen as complicating
the software, and endorsing a feature that's opposed to the
fundamental aim of open knowledge.
Another thing to bear in mind is that if there are enough features wanted by 'business' or 'the real world' or whatever you want to call it, which the developers deliberately avoid implementing then the project may end up forking.
Whether this is a Good Thing or not, I guess depends on your persepective.
- Mark Clements (HappyDog)
On Wed, Aug 30, 2006 at 06:27:32PM +1000, Nick Jenkins wrote:
The more interesting question is: If people can find a way of adding this type of functionality to the default install (but disabling it by default) so that it doesn't impact you, should it be added?
Why not?
Worst case: if you want to add something that the development team feels is so fundamentally incompatible with their ethos (or, more likely, so complicated and prone to increase suppot load :-) that they Just Won't Put It In, either fork, or, more likely, just maintain it as a patch/dropin, and track the releases. It's *still* easier than writing all of MediaWiki yourself.
On the plus side, it'd most likely lead to more deployments of the software, and hence more people familiar with the syntax, and more people familiar with wikis in general, and what people get used to at work they tend to use at home too (with potential positive impact). On the negative side, maybe it's seen as complicating the software, and endorsing a feature that's opposed to the fundamental aim of open knowledge.
Well, at the risk of pissing people off, I'm gonna come down on the "who gives a shit" side of that.
Someone has to be more Catholic than the pope, for progress to happen -- but that's rms' job.
IMHO.
Cheers, -- jra
On 30/08/06, Jay R. Ashworth jra@baylink.com wrote:
Someone has to be more Catholic than the pope, for progress to happen -- but that's rms' job.
*snigger*
Cue the usual "Stallman is our god! He is the second coming and He will save us all!" vs. "He's an unwashed hippie hacker" arguments.
We have JWPII's sometimes. Thank god for The Brion; he weilds the WONTFIX to end all WONTFIXes. Or something cliché like that. Given some of the crap that comes out of BugZilla, this is quite a sensible suggestion, but ultimately, I personally think it conflicts with the whole "wiki, open editing, vandalism free-for-all" spirit of MediaWiki.
Rob Church
On 8/29/06, Rob Church robchur@gmail.com wrote:
The referenced bug is a long standing feature request that we don't have plans to implement, owing to the fact that it contradicts a lot of the "ethos" of MediaWiki; its purpose and concept.
Hm. Example from Wikimedia environment: There are more and more private wikis which are only for members of boards (wmf/chapters) or committees or internal.wikimedia etc. I think it would be definitely nice to have an option to disable a user's account (as in he can't see any pages anymore and is treated as if he had none account at this private wiki) e.g. if he retires from this board/committee/whatever. Michael
Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 30/08/06, Michael Bimmler mbimmler@gmail.com wrote:
Hm. Example from Wikimedia environment: There are more and more private wikis which are only for members of boards (wmf/chapters) or committees or internal.wikimedia etc. I think it would be definitely nice to have an option to disable a user's account (as in he can't see any pages anymore and is treated as if he had none account at this private wiki) e.g. if he retires from this board/committee/whatever.
I'm not disputing the account locking feature.
Rob Church
On 8/30/06, Rob Church robchur@gmail.com wrote:
I'm not disputing the account locking feature.
Okay. Seems I misread which bug/feature you were talking about. Michael
Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 30/08/06, Michael Bimmler mbimmler@gmail.com wrote:
Okay. Seems I misread which bug/feature you were talking about.
I have stated, and continue to maintain, that to implement strong, per-page access controls, to the level that some organisations require, within MediaWiki would require a considerable rewrite and a rethink of a lot of aspects of the software, and that such a change would *not* be consistent with the purpose and intended use case for MediaWiki.
Organisations which "cannot implement MediaWiki" because of this should seek an appropriate document management solution for their needs, that is, obtain (purchase, if needs be - it would be worth it) software that was *written for their intended use*. MediaWiki as a project isn't seeking to become the world's #1 commercially-used wiki package.
I do not, however, dispute the other bug report; that which calls for locking and hiding of certain accounts, since I accept it would be useful to the main audience at which MediaWiki is targetted; the Wikimedia projects.
Rob Church
On 8/30/06, Rob Church robchur@gmail.com wrote:
I have stated, and continue to maintain, that to implement strong, per-page access controls, to the level that some organisations require, within MediaWiki would require a considerable rewrite and a rethink of a lot of aspects of the software, and that such a change would *not* be consistent with the purpose and intended use case for MediaWiki.
No one seems to have mentioned the obvious, which is that in these cases the best thing is probably just to lock down the whole webserver with a name and password. Where I'm working now does that and it works perectly well - we have about 5 different MediaWiki wikis, and different people have access to different ones.
Steve
On Wed, Aug 30, 2006 at 12:01:20PM +0100, Rob Church wrote:
On 30/08/06, Michael Bimmler mbimmler@gmail.com wrote:
Okay. Seems I misread which bug/feature you were talking about.
I have stated, and continue to maintain, that to implement strong, per-page access controls, to the level that some organisations require, within MediaWiki would require a considerable rewrite and a rethink of a lot of aspects of the software, and that such a change would *not* be consistent with the purpose and intended use case for MediaWiki.
"... for it's primary development customer, the Wikimedia Foundation, who are paying the bills." But I undersatdn your point, entirely, Rob; don't take that as a challenge.
Organisations which "cannot implement MediaWiki" because of this should seek an appropriate document management solution for their needs, that is, obtain (purchase, if needs be - it would be worth it) software that was *written for their intended use*. MediaWiki as a project isn't seeking to become the world's #1 commercially-used wiki package.
Quite so.
I'm very fond of WebGUI, which has one of the two major wikiattributes, easy page creation and version tracking/revert, now. Adding the other one.
The other attribute -- easier text markup through wikitext -- it does not have, but it wouldn't be that hard to add.
Cheers, -- jra
wikitech-l@lists.wikimedia.org