Last modified: 2012-11-03 19:09: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 10493 - Setting a temporary usergroup (allow expiry of user rights via Special:UserRights form)
Setting a temporary usergroup (allow expiry of user rights via Special:UserRi...
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Low enhancement with 16 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6796 12835 16509 (view as bug list)
Depends on:
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2007-07-07 17:09 UTC by Davide21
Modified: 2012-11-03 19:09 UTC (History)
17 users (show)

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


Attachments

Description Davide21 2007-07-07 17:09:51 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.
Comment 1 Chad H. 2007-07-07 21:32:39 UTC
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?
Comment 2 Casey Brown 2007-07-07 21:34:18 UTC
Too much work for too little good.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-08 03:25:04 UTC
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.
Comment 4 ais523 2007-07-09 10:12:22 UTC
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?
Comment 5 Chad H. 2007-07-09 11:58:26 UTC
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.
Comment 6 Brion Vibber 2007-07-09 14:51:59 UTC
No need for a job, just remove expired entries on demand.
Comment 7 Chad H. 2007-07-20 23:37:03 UTC

*** This bug has been marked as a duplicate of bug 6796 ***
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-22 02:42:50 UTC
Bug 6796 has less comments/info, I'll mark that dupe of this instead.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-22 02:42:54 UTC
*** Bug 6796 has been marked as a duplicate of this bug. ***
Comment 10 Effeietsanders 2007-07-22 07:24:28 UTC
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. 
Comment 11 Majorly 2007-08-18 20:39:29 UTC
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.
Comment 12 Helios 2007-08-19 16:03:10 UTC
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?) ?

Comment 13 SJ 2007-10-11 08:09:15 UTC
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
Comment 14 SJ 2007-12-24 01:53:22 UTC
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.
Comment 15 SJ 2008-01-30 05:48:19 UTC
*** Bug 12835 has been marked as a duplicate of this bug. ***
Comment 16 Filip Maljkovic [Dungodung] 2008-11-30 23:33:50 UTC
*** Bug 16509 has been marked as a duplicate of this bug. ***
Comment 17 Splarka 2009-05-01 15:48:14 UTC
summary++ for dupe catching
Comment 18 Daniel Friesen 2012-10-23 03:39:53 UTC
...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.

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


Navigation
Links