On 29/08/06, Dion Rowney <dion_rowney(a)hotmail.com> wrote: 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

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

On Tue, Aug 29, 2006 at 10:18:12PM +0100, Rob Church wrote: Sure. Just like groups. And read-protection by groups. :-) Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 The Internet: We paved paradise, and put up a snarking lot.

On 8/29/06, Rob Church <robchur(a)gmail.com> wrote: 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. -- -george william herbert george.herbert(a)gmail.com

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.

On Wed, Aug 30, 2006 at 06:27:32PM +1000, Nick Jenkins wrote: 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. 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 -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 The Internet: We paved paradise, and put up a snarking lot.

On 8/29/06, Rob Church <robchur(a)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. Michael

On 8/30/06, Rob Church <robchur(a)gmail.com> wrote: Okay. Seems I misread which bug/feature you were talking about. Michael

On 8/30/06, Rob Church <robchur(a)gmail.com> wrote: 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