Last modified: 2012-11-03 19:09:44 UTC
On italian wikipedia, due a recently found mass copyvioler user, came up the need of some temporary sysops. I think it would be quite useful that bureaucrats have the opportunity to set the duration for the flag, as normally occours with blocks or protections. The majority of adminship duration will be for example "infinite", but for some case it would be useful to have a adminship that expires. Thank you in advance for your consideration, Davide21.
This would require an additional field added to the user rights table, signifying when the permission was to expire. However, wouldn't this create a mess over time, with all these extra expired permissions in the database?
Too much work for too little good.
Probably not optimal. If this kind of thing is desired it's simplest to just allow bureaucrats to desysop. I certainly don't think this has enough general utility to be put in the core software, so refiling as an extension request.
What about creating a new usergroup that's identical to "sysop" (say "temp-sysop"), but can be granted and removed by bureaucrats, as opposed to being granted by bureaucrats and removed by sysops?
I see this working one of two ways, both requiring a permission_expiry field added to the user permissions table. Method A) There is a job that is run once a day (or hour?) checking to see if those people with an expiry time have expired yet, and if so to remove the flag. Method B) Rewrite the user permissions checks to see if you've expired, and if not, then apply the permissions, if so, skip it. Method A's major drawback is it's not integrated with the code base, and having to run an external job is less-than-perfect. The major problem with method B is that it would require major changes in how user permissions are applied. As Casey said, I think it's too much work for too little good. I recommend WONTFIX.
No need for a job, just remove expired entries on demand.
*** This bug has been marked as a duplicate of bug 6796 ***
Bug 6796 has less comments/info, I'll mark that dupe of this instead.
*** Bug 6796 has been marked as a duplicate of this bug. ***
Just note that bug 6797 was somehow different, because that was about the rights that stewards are giving out, and they actually give out temporary sysopships quite often. But the process to de-admin them again after a agreed time is quite bureaucratic and very often with a huge backlog as it is forgotten all the time. It would be a lot easier for the stewards if they could set (from meta) an expire *optionally* (there are also sysops who need to get normal sysopship from the stewards for an infinite time). I am thinking of a similar construction as that with the protected pages (at least, on the user-side :) ) Thanks, Lodewijk.
Well I was just discussing this, and I think that expiry times would be a very useful feature for stewards, who frequently give out temporary rights to users.
I like the idea of an additional usergroup called "temporary sysop" which could be managed also by bureaucrats, which often (not as often as stewards on minor wikis) have to sysop somebody and call for a steward to desysop them after the expiration of the charge. Would it be so unpractical to add this usergroup (much coding?) ?
This would be useful as a paradigm, not simply for the specific cases mentioned here and in my original report (bug 6796). They are different facets of the same functionality : allowing permissions and restrictions to time out. This is the reason to include it in the core system and not as a third-party extension. Other uses might include : wikis that want to have admins reelected every year could offer two options: year-long or day-long adminship (for 'normal' and emergency admins). accounts being used for one-time bot edits could get a one-week bot flag. someone wanting a wikibreak could have negative permissions (no editing) granted until the end of term... SJ
This just came up again on the stewards mailing list. Additionally: the current system does not allow for transparency of intent; an admin or steward who intends to grant temporary rights has no explicit way to indicate that, and must make do with an edit summary. As the difference in intent between an emergency sysopping and a community decision to sysop are so different, I can imagine making them different privs altogether. However, we should at least make this difference explicit.
*** Bug 12835 has been marked as a duplicate of this bug. ***
*** Bug 16509 has been marked as a duplicate of this bug. ***
summary++ for dupe catching
...I could see this working fine in core. Might want to do it alongside other improvements to our permissions system. Improve autopromote; Make it less of a hack. And improve it's capabilities. Support extra things like expiry on normal permissions. Consider simplifying group inheritance. Support restricted permission sets for some things. I've seen some use cases for something like a edit or delete capability restricted to a namespace. Consider some sort of individual right grant rather than group membership or some sort of capabilities group. Some of those use cases for restricted rights would be a mess if each of them needed a manual group. Some of these things are actually things that the OAuth use cases have been wanting and we'll need general support for within the software in order to implement in OAuth. For OAuth support some sort of capabilities interface with a User::getCapabilities method and capabilities we attach to an individual user instance. Then OAuth could define a capabilities instance that would use scope rights but ensure they lie within the user's given rights. And likewise it could nest those recursively to properly support refresh tokens granting rights with smaller scopes. Course I don't have time to write up the details or code.