Last modified: 2005-06-25 00:15:13 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 2107 - Create a table of privileges or a privilege capability word or level
Create a table of privileges or a privilege capability word or level
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 2422
  Show dependency treegraph
 
Reported: 2005-05-08 08:52 UTC by Paul Robinson
Modified: 2005-06-25 00:15 UTC (History)
1 user (show)

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


Attachments

Description Paul Robinson 2005-05-08 08:52:13 UTC
I recommend that the current system of priveleges be 
changed to a type of table based upon a word in the
database as a bit-level privelege mask, or upon a 
set of flags.

I understand under the current system there are 
basically something like 5 or 6 levels of privelege, 
something like guest, logged-in user, bureaucrat, 
sysop, administrator, programmer.

I would like to recommend creation of a privelege 
flag field consisting of perhaps 32 or 64 bits of
privelege, such that more fine-grained control can
be made as to what can or cannot be done.  This would
allow certain features of the system to be made 
available or denied depending on which flags the user
has set.

If this capacity already exists, please excuse me, 
the last time I read the source code to the program I
did not notice it.  

Now, the number of privelege classes doesn't have to
be 32 or 64, I just thought of that from the size of
a word or double word, which could be stored in the
database.  In a program I wrote once, I created a
table of 50 different priveleges, each being a single
boolean entry.  

Another possibility is to allow pages to be assigned
a minimum user level to be able to be edited directly,
or having edits by users below that level to be sent
to a person (or the group) having edit authority.  
This would also go along with being able to have 
certain classes or types of articles to have some 
level of "authority" assigned to them.

Most articles can be assigned a value of 0, meaning 
anyone can edit them.  Occasionally some articles 
can be raised because of edit wars, without having 
to use a binary lock/unlock on the article, where 
there is a party who is known to be more reliable, 
they can be allowed to do edits on the particular 
disputed article, without they themselves having the
authority to decide to make the article blocked.  
This would then allow a person with priveleges to 
take the article out of an edit war, by simply 
raising the user level needed to edit it, then users
who have shown to have more responsibility can be 
allowed to make changes, without the user who raised
the access level having to get involved, thus 
increasing the capacity for neutrality.

What the format of the privelege table is can be 
whatever is appropriate depending upon what is 
desirable to use in the database.  It can be a table 
of bytes, or anything you want to use, since it 
attaches to the user's account, it's not a huge amount 
of space as opposed to it being something that is 
attached to every single article (except for a 
minimum edit level requirement, or access bit table).

This would also allow consolidation of all of the
different priveleges and capabilities into one part
of the database instead of being a whole bunch of
different parts interspersed into lots of different
sections.

This also would allow persons re-implementing the 
Wiki to provide different levels of access for 
different users, and could allow some bits to be
used for tying some content to certain privelege
levels, for example, the Main Page cannot be edited 
unless you have a higher level of privelege.  I
guess this is a function of threats of vandalism,
and is an unfortunate change.

Had this restriction been in effect when I thought
up the idea of putting in a quick index in Wiktionary,
I would have been unable to do so.  I note that once 
I had the idea of including a quick index, it was 
such a good idea that it has remained as a permanent
feature of the first page of Wiktionary.  I was able
to implement this really useful feature immediately,
and make something available to everyone as a result.

Having the front page edit privelege be given to some
people, for example, someone who just needs that 
capability doesn't need to have the capability to 
block other users, and so on.  It can be used to give
finer-grained control where it is needed.  

Again, it's not necessarily for Wikimedia to use the
extra control, but potentially for other systems to 
be able to use it.  For example, a company could set
up a wiki about their products that allows people to 
make changes, but the pages that are about the company
itself or that represent certain material that is
critical can be made non-editable by most users, but
some trusted users - who are not necessarily 
employees - can be given priveleges to change those 
classes of pages, or perform other functions, without 
necessarily being able to change everything or do 
other changes which for legal or technical reasons
they should not have the capacity to do.
Comment 1 Brion Vibber 2005-06-25 00:15:13 UTC
See $wgGroupPermissions and use of user_groups table in 1.5.

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


Navigation
Links