Last modified: 2011-01-25 01:36:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6952 - Migrate some "safe" config options to similar in-wiki settings
Migrate some "safe" config options to similar in-wiki settings
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-08 22:54 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2011-01-25 01:36 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-08 22:54:02 UTC
We see lots of bug requests here that require someone with shell access to add
new namespaces, enable Wiki.png, etc.  Why not eventually let
bureaucrats/stewards do some of the stuff that doesn't require technical
knowledge, from in-wiki?  (Obviously these options would all be moved out of
LocalSettings.php and into the database somewhere.  Maybe they could even be
killed as globals and switched over to constants instead . . .)

As long as the options are easily reversible, there's no security issue.  It's
probably best to tack everything uncomplicated and easily reversible into this
bug proposal, in fact, because GUIs are more friendly than file-editing, except
that on WMF sites there are some things that 'crats shouldn't be allowed to
touch (e.g., $wgGroupPermissions['*']['edit']).

Some of the following would be suitable options for eventual inclusion:

* $wgEnableUploads (some WMF wikis want everyone to upload to Commons instead,
for instance)
* $wgGroupPermissions (for adding new groups *only*, at least on WMF sites, a la
rollback or whatnot; only really useful to us once we get a more flexible
group-assignment mechanism so stewards won't have to be bothered constantly,
although other sites with more active userrights-enabled groups might appreciate
it more)'
* Maybe $wgRestrictionLevels, if it works as one would expect?  Particularly
useful if some wiki wants to introduce a "semi-sysop" group of some kind. 
Probably only allow people to touch custom entries, not the current three, or
else things could break.
* $wgNamespacesWithSubpages (if it can't screw up existing names with slashes in
them)
* $wgNamespacesToBeSearchedDefault
* $wgImportSources (but maybe have a list of valid sources set from text file
for use in WMF projects; trying to import from Meatball: would probably be Bad)
* $wgImportTargetNamespace
* $wgExtraNamespaces (obviously not in present form, which is way too easy to
break stuff with; progress was made at some point with [[m:Help:Namespace
manager]], but that seems to have died)
* $wgForceUIMsgAsContentMsg (unless this can break stuff)
* $wgContentNamespaces

Presumably a new permission like 'config' would be added to handle this, with
bureaucrats getting it by default.
Comment 1 Rob Church 2006-08-08 23:36:56 UTC
There are a multitude of reasons we don't allow bureaucrats to set site
configuration. This is the cause for having a team of system administrators to
do the work; they understand exactly what each case does, and know what
supplemental work (maintenance scripts, etc.) needs to be performed for each.
The old argument that "the developers [sic]* don't work hard enough" is
bollocks, but if you do feel that, then be a bit more persistent.

A number of the configuration options above are NOT suitable to be edited by any
old Joe Smith who the community trusts, and many are NOT innocuous and
unbreakable. Trust does not equal expertise, and I would predict the larger
wikis breaking down within moments. Fuck 3RR, just think of the config. wars.

Next up, performance. Storing this stuff in the database means we have to go
digging it up when we want it. Right now, use of the SiteConfiguration class and
the caching for it means that on sites like Wikipedia, MediaWiki takes less time
to initialise and it's optimised.

I am absolutely against handing over access of this nature to end users who are
elected through voting farces.


* Developer != System administrator. The former codes, the latter administers.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-09 00:53:59 UTC
I never suggested the options *as currently implemented* should be editable.  I
suggested that the *concepts behind the options* should be editable.  I
apologize if that wasn't clear enough.  Any change of something that required a
maintenance script . . . would run the maintenance script.  If there's a problem
with running a maintenance script every time an option needs to be changed, then
that's not "safe" and is unrelated to this bug (see: summary word two).  There's
no drawback in allowing bureaucrats to change what checkboxes are on by default
in Special:Search (see, e.g., bug 6306).

I'm not making firm suggestions about implementation, I'm just saying that some
*choices* that can currently be implemented only by developers could be allowed
for implementation by bureaucrats, and that this would have benefits in terms of
responsiveness to our smaller wikis, just as the original creation of the rank
relieved developers of the need to promote sysops.  Do you have a problem with
the namespace manager?

(P.S.: enwiki and a few of the other large wikis elect bureaucrats, but most
wikis with a bureaucrat have only one, steward-appointed.  Even the largest have
only a few active bureaucrats — roughly eight or so on enwiki — and I've never
heard of either a bureaucrat- or steward-war.)
Comment 3 Happy-melon 2009-04-12 12:51:32 UTC
This is [[mw:Extension:Configure]].
Comment 4 Roan Kattouw 2009-04-12 13:54:30 UTC
(In reply to comment #3)
> This is [[mw:Extension:Configure]].
> 

Closing this as fixed; please open separate bugs to request more features in Configure or for Configure to be enabled on WMF wikis.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links