On 07/02/13 11:05, David Gerard wrote:
What in Confluence are you thinking of MediaWiki as lacking?
The main two in my experience are (1) firm access control (2) WYSIWYG editor. (1) is just not something MW can promise to do securely unless pretty much every developer cared and (2) is on the way (certainly before the end of time). Any others of importance?
MediaWiki has internal interfaces which support fine-grained write permissions right down to the level of individual pages edited by individual users. Consider how fine-grained AbuseFilter is, for example. These interfaces are old and are used by everything. So for write permissions, any ACL model you can think of can be slapped on top as an extension and will be robust.
For read permissions, the options are coarser, but whitelist read wikis are reasonably secure, even in the presence of naively written extensions, since the usual entry points (API, RL, action=ajax, special pages) are restricted by default.
Wikimedia uses whitelist-read wikis for all sorts of sensitive data. The usual approach is to separate private data with different audiences into different wikis. That would be more feasible for small sites if multi-wiki installation and management was easier.
So I don't think the situation with access control is as bad as people make out.
For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
This is not something WMF is interested in doing, that has been made extremely clear in the last year.
-- Tim Starling