Last modified: 2005-06-25 00:15: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.
See $wgGroupPermissions and use of user_groups table in 1.5.