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