Steward requests/Miscellaneous

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
← Requests and proposals Steward requests (Miscellaneous) Archives→
Shortcut:
SRM
This page is for Wikimedia wikis having no active administrators. Requests can be made here for specific administrative actions (such as page deletion) to be performed by a steward or global sysop. In other cases:
  • If the wiki does have active administrators, file the request with one of them.
  • If the wiki has an active editor community, any potentially controversial action (deletion of actual content, edit to a protected page, renaming of a protected page, etc.) should receive consensus from the wiki community before being requested here, and a link should be provided to that consensus in the request.
  • For global lock/block requests, file a request at Steward requests/Global.
  • For non-controversial deletion requests such as empty page, simple spam or vandalism, and non-controversial or emergency requests to block vandals, spammers or other malicious users, you may use global sysop requests instead.
  • If a consensus is considered required to act, similar principles apply as expressed at Steward requests/Permissions/Minimum voting requirements, and can be used for guidance to how and what should be done at small and medium communities to gain a consensus.

To add a new request, create a new section header at the bottom of the "Manual requests" section using the format below: 

=== Very brief description of request here ===
{{Status|In progress}}
Give details about your request here. --~~~~

It is helpful if you can provide a link to the wiki (or the specific page on the wiki) in question, either in the header or in the body of your request.

When reporting cross-wiki vandalism, the following template calls can be used to link to a user's contributions across all Wikimedia content wikis (these are for logged in users and non-logged-in users, respectively):

* {{sultool|Username}}

* {{luxotool|IP.address}}

Template {{LockHide}} can also be used in appropriate cases.

To request approval of OAuth consumers please use {{oauthapprequest}} (see the documentation before using).

Old requests are archived by the date of their last comment.


Cross-wiki requests
Meta-Wiki requests


Bot-reported requests[edit]

See Global sysops/Speedy delete requests.

Manual requests[edit]

Import template used by twinkle from enwiki[edit]

Status:    In progress

We recently imported a direct version of Twinkle gadget from enwiki to our local kswiki. However, we have not imported all templates used by two twinkle. I request you to kindly import templates from en:Category:Templates used by Twinkle to ks wikipedia kindly don't import the templates that are already present as most of them have been translated. I know this may be hectic, If this twinkle is discouraged for small wikis like kswiki, Then can you kindly install Global twinkles as a gadget. I will leave the change upto you as you are more experienced than me. Thankyou. --Iflaq (talk) 05:40, 2 October 2021 (UTC)[reply]

@Iflaq: If there is only one or two people going to use this, then it would be better for you to install it through your special:MyPage/global.js per the instructions at User:Xiplus/TwinkleGlobal. We can set it up as a global gadget if there are going to be plentiful users. Running the English version is not the best idea.  — billinghurst sDrewth 15:20, 3 October 2021 (UTC)[reply]
FWIW There are a massive 848 templates at enWP in play with Twinkle and that is just crazy. Seems gross overkill, and setting a rod for your back, to coin a phrase.  — billinghurst sDrewth 15:23, 3 October 2021 (UTC)[reply]
Billinghurst, Thankyou for your advice. Can you please create Global twinkle as a Gadget for our wiki. Since the enwiki needs many templates which are not present and translated it seems odd to use it. I will be importing and localising them one by one till then we can ise global twinkle as a Gadget. Thankyou. Iflaq (talk) 03:20, 4 October 2021 (UTC)[reply]
TwinkleGlobal is a cross-wiki script. It doesn't require any local templates. And it doesn't follow any local administrative process. So it's better to install twinkle from enwiki then localize it. Xiplus (talk) 07:38, 4 October 2021 (UTC)[reply]
The key point is how many functions do you want to use? For example, if you don't need to tag articles with Cleanup Tempaltes, you don't need to import those templates. Xiplus (talk) 07:43, 4 October 2021 (UTC)[reply]
If i get it right Xiplus, You are suggesting to Import and translate Enwiki Twinkle not Global Twinkle ? If so it would be better if someone can import all templates from the enwiki and the we will translate them according to our needs. Though some of them may not be used currently but can be used in future. Thankyou. Iflaq (talk) 11:58, 4 October 2021 (UTC)[reply]
How is the AFD process on kswiki? I can't find any related pages. I think there is no such process on kswiki, so you should not import AFD-related templates. Xiplus (talk) 12:46, 4 October 2021 (UTC)[reply]

Thanks for your guidance Xiplus. So the question Iflaq which functions are you're wanting to have Twinkle using at your wiki? Maybe Xiplus can guide you on the required components for you wiki, as it seems that all the functionality of Twinkle is not required on a less complex wiki.  — billinghurst sDrewth 13:59, 4 October 2021 (UTC)[reply]

The function (component) list is here. Xiplus (talk) 15:14, 4 October 2021 (UTC)[reply]
Sure Xiplus, Billinghurst got it. I have created a page that depicts our need ks:User:Iflaq/Research. Is there a way to import these templates faster than manually importing them one by one. Iflaq (talk) 05:06, 5 October 2021 (UTC)[reply]
Iflaq, is there still action needed regarding this request, or is it okay to close? Vermont (talk) 02:32, 28 February 2022 (UTC)[reply]

Edit Interface of fa.wikibooks.org[edit]

Status:    In progress

I raised the issue on the VP and no one opposed it: fa:b:Special:Permalink/113740#تغییرات_رابط_کاربر

Please see b:fa:بحث_مدیاویکی:Common.js#Request_for_changes_moved_from_meta for the requested chnages.

My previous request was archived unsuccessfully: Steward_requests/Miscellaneous/2021-10#Edit_Interface_of_fa.wikibooks.org

Please note that the proposed changes have been taken from the English Wikibooks. If the English Wikibooks can have them, then Farsi Wikibooks can have them too. I'm not a regular editor of that project. I was asked to take care for this change, and I did that as a favour. I am a volunteer and not going to invest more time to look for better solutions. So, let's just copy&paste what I have prepared so far. I miss the old days when you could simply ask a local admin to edit the interface :(

Thanks, 4nn1l2 (talk) 03:53, 16 October 2021 (UTC)[reply]

@4nn1l2 What does this script do that the built-in .mw-collapsible doesn't? AntiCompositeNumber (talk) 02:41, 28 February 2022 (UTC)[reply]

Configure a Wikiset to opt out fawiki from GIBPE[edit]

Status:    In progress

Based on local community consensus at fa:ویکی‌پدیا:نظرخواهی/اصلاح_وپ:معاف#مستثنی_شدن_ویکی‌پدیای_فارسی_از_دسترسی_سراسری_معافیت_از_قطع_دسترسی_آی‌پی, I am requesting on behalf of fawiki that a Steward sets up a Wikiset here on Meta using which fawiki is opted out of GIPBE permission. All users who wish to bypass local or global IP blocks on fawiki shall request it locally at fa:ویکی‌پدیا:درخواست برای دسترسی/معافیت از قطع دسترسی نشانی اینترنتی.

I also suggest that GIPBE be edited to mention the above and provide a link to fa:ویکی‌پدیا:درخواست برای دسترسی/معافیت از قطع دسترسی نشانی اینترنتی. Furthermore, I propose that MediaWiki:Wikimedia-globalblocking-ipblocked-range is edited to include the following phrase: "If you have Global IP block exemption right, you may still need to request and receive local IP block exemption right on some projects".

The second paragraph consists of suggestions only; the community's wish, expressed in the first paragraph, would best be granted regardless of whether those suggestions are agreed to or not. Please {{ping}} me if you have any questions. Huji (talk) 01:25, 19 January 2022 (UTC)[reply]

Was the community informed that GIPBE only applies to global blocks and for local blocks people need to apply for local IPBE anyway? --Base (talk) 11:39, 19 January 2022 (UTC)[reply]
Huji, ^. --Base (talk) 11:39, 19 January 2022 (UTC)[reply]
@Base: yes. Fully aware. Huji (talk) 13:22, 19 January 2022 (UTC)[reply]

Can I voice my opposition to this. Global block means global. Global IPBE is to cover stewards actions. If you wish to locally block someone use local blocks. gIPBE is not circumvent any local blocks of a person or an IP address.  — billinghurst sDrewth 23:48, 19 January 2022 (UTC)[reply]

@Billinghurst: of course you can! And User:Martin Urbanec also shared some similar comments which you can now find in User_talk:Martin_Urbanec/Archives/2021#Global_group_opt-out_configuration. In short: (a) proxy blocks are often at the global level only, and for good reason (why repeat thousands of blocks on every project?); (b) fawiki is "special" in the number of its users who use proxies; (c) users who almost exclusively edit on fawiki have evaded proxy blocks by obtaining GIBPE and at least on two occasions, this has had negative consequences on local CUs' ability to run investigations on said users; and (d) if Stewards decide to reject the local community's wish, which I hope they don't, their decision would only be symbolic because fawiki will move on to the next option which is to import all global proxy blocks as local blocks, whereby GIPBE will become practically ineffective at fawiki.
So, you all are free to do as you wish. The outcome, one way or the other, is that fawiki will not allow anyone to circumvent blocks on open proxies unless they have locally been given IPBE access. Huji (talk) 00:08, 20 January 2022 (UTC)[reply]
What I am hearing is that there is something broken in the allocation of gIPBE that people have got through who should not, rather than allowing stewards to let through people are affected by their blocks. Your proposal is contrary to the whole scope and current design of global blocks and stewards' management of their blocks. It becomes a management nightmare. I believe that that this should be a global RfC due to what it could portent.  — billinghurst sDrewth 01:35, 20 January 2022 (UTC)[reply]
AND two occasions of slipping in the gIPBE is truly minor. How many socks do you have all the time, and people using unblocked proxies. It is an unproportional response to the problem and using a sledge hammer to crack a nut.  — billinghurst sDrewth 01:37, 20 January 2022 (UTC)[reply]
AND I wonder whether it is possible to omit a wiki, as the permissions look to be set by an extension, and not by a wikiset, so what ability is there to withdraw them with a wikiset?  — billinghurst sDrewth 01:45, 20 January 2022 (UTC)[reply]
@Billinghurst: Starting from your last point: I was told that Wikisets can be used here; if that is incorrect, I am happy to explore a way to modify the extension code or WMF config for it.
Your first point is accurate: part of the issue is GIPBE is given out not to users who are editing cross-wiki and are impacted by non-proxy IP blocks, but to users who are nearly exclusively editing in one or two projects and who are impacted by proxy IP blocks. But another part of it is that GIPBE may work for many projects, but its cost-benefit tradeoff is not the same for all projects. Specifically, for projects in which sockpuppetry through proxies is more common.
Again, I refer you to the discussion I had with Martin, in which I explained the three-step solution. Step one: reach consensus GIPBE should be given out more thoughtfully (Requests for comment/Global IPBE guidelines was created, but failed). Step two: reach consensus that GIPBE should not apply to certain projects in which the rate of open proxy use and sockpuppetry is high (consensus achieved on fawiki, request presented here is getting push back by you and formerly by Martin). Step three: make GIPBE obsolete on those projects (starting with fawiki) by importing hundreds of thousands of blocks (retrospectively and prospectively).
And guess what: if a user complains about the local block of a proxy where the block is imported from a global block, local community will not take responsibility for it and will refer the user to Meta to discuss the global block. So, once again, I emphasize that you all are free to choose what you want to do. The outcome is the same. The third option is just produces more workload for no good reason. Huji (talk) 13:36, 20 January 2022 (UTC)[reply]
Please do not expect any user to go to a user talk page to read about a proposal, and its history, the proposal should be a standalone proposal presented to the community in its entirety. This approach is a de facto attempt to circumvent the principles and fundamentals of global block and gIPBE and it should be put before the community to see whether any wiki has the right to opt-out of that system. Such changes belong as global RfCs. Your proposal simply makes it harder to explain the global system and so far this is due to two identified users, and where it relates to the application of rules of gIPBE by stewards.  — billinghurst sDrewth 20:52, 20 January 2022 (UTC)[reply]
zhwiki (which has a high rate of usage of open proxy due to GFW) choose the third option, we have an adminbot blocking OP. Since nearly all global blocked OP has a hard block locally, this seems not a problem if you guys reach the consensus of option 2. Stang 14:59, 20 January 2022 (UTC)[reply]
@Stang: would you think that if this proposal is implemented for fawiki, zhwiki would also seek to be in the opt-out and stop importing the blocks? Huji (talk) 17:07, 20 January 2022 (UTC)[reply]
That's the community's decision, but imo unlikely because a lot of locally blocked OP range is not blocked globally. Stang 17:10, 21 January 2022 (UTC)[reply]
I think that a simpler solution is that you should track the applications for the GIPBE and raise an objection in any questionable case. I actually have not recently seen a lot of users from fa.wiki requesting the GIPBE. Ruslik (talk) 21:03, 20 January 2022 (UTC)[reply]
@Ruslik0: It should be the user's responsibility to prove that they are impacted by a global non-proxy block; it should not be our job to prove that they are not, and are getting GIPBE to abuse proxies. If Meta fails to ascertain that, and fails to adopt a guideline to do so (see RfC link above), then instead of arguing with those individual users on Meta when they ask for GIPBE, I'd rather just do the obviously defensible thing: blocking all proxies locally.
Anyway, it seems like the gravity of the situation is not understood despite my multiple tries. Clearly, the other large wiki that I know would benefit from it (zhwiki) also has given up on Meta already and taken option #3. I am going to start importing blocks in a few days. It is up to Meta to decide if they think that should be the end of it (and close this request) or if all aspects of proxy blocks should be actively managed globally, in which case exemptions from them should be very selectively given.
Another option Meta may want to pursue: work with Extension developers to separate global proxy blocks from other global blocks, and then use GIPBE to exempt users from non-proxy global blocks only (and possibly use another very selectively given right to allow some users to globally evade proxy blocks).
I am keeping this request open because it seems like Stewards are choosing the overrule a local consensus, and this needs to be explicitly stated here and kept in the history.Huji (talk) 16:17, 22 January 2022 (UTC)[reply]
@Huji Please stop accusing stewards of overruling/ignoring consensus. No steward ever said anything like that in this discussion (nor elsewhere) and there was no decision made yet. As you can see, some of the wikimedians sharing their thoughts here are not stewards and as such, they can't speak on behalf of the stewards. The only stewards (me and @Ruslik0) who shared their opinion on this matter made it crystal clear it's their personal opinion only. As the SP says, "[stewards] do not lose the ability to think and feel because they have access to more buttons". Sincerely, Martin Urbanec (talk) 16:43, 22 January 2022 (UTC)[reply]
I am not sure what it has to do with the local consensus? Stewards decide, which IPs are globally blocked, and they also can exempt some users from their own global blocks. In addition, stewards are under no obligation to block all open proxies and moreover can unblock some of them if necessary. So, one wiki cannot dictate how global blocks are applied and who is exempted from them. Ruslik (talk) 21:05, 22 January 2022 (UTC)[reply]
@Martin Urbanec: Your point is fair: I should have used a conditional statement ("if the Stewards choose to overrule the local consensus ..."). Huji (talk) 20:46, 22 January 2022 (UTC)[reply]
Note: the reason of blocking webhost IP (i.e. proxy) in zhwiki is excessive proxy abuse by LTA, which is unrelated to GIPBE. See also local discussion. Thank you. SCP-2000 16:55, 22 January 2022 (UTC)[reply]
The reason for fawiki asking to be exempt from GIPBE is the same.
I think part of the problem is that a few projects have a much higher rate of proxy use than most other projects.
Another part of the problem is the way proxy blocks are executed (globally) and exemptions are executed for them via GIPBE (also globally, without considering impact on specific local communities). Huji (talk) 20:48, 22 January 2022 (UTC)[reply]
BUT All gIPBE does is reverse the impact of a stewards' action. It does nothing more or less. One gIPBE puts ONE specific account back to the status quo of the account, so that ONE account has the same editing rights as anyone not impacted by a steward's block. Stop beating this up to be more than it is. We all have problematic users, we all have users who abuse from dynamic ranges that cannot be blocked. Your wiki can use its granted rights and block problematic ranges just like any other. You have not been talking large numbers, and you have every opportunity to identify improvements to the system to the allocation of gIPBE WITHOUT having to change the bedrock of what global blocks and gIPBE are meant to be doing globally.  — billinghurst sDrewth 23:04, 22 January 2022 (UTC)[reply]
Comment CentralAuth developer note: Technically speaking (not commenting on if this is a good idea to implement) this can be done by creating an opt-out wiki set with fawiki in it, and then changing the GIPBE group to use that wiki set. Majavah (talk!) 15:08, 20 January 2022 (UTC)[reply]

For context, please see prior discussion about this at my talk page. --Martin Urbanec (talk) 00:05, 20 January 2022 (UTC)[reply]

@Huji: I've sent an email to the stewards internal mailing list to discuss this. Would you mind waiting at most two weeks (probably less than that, but giving us a reserve here) to go ahead with the local blocks? Thanks, —Thanks for the fish! talk•contribs 17:16, 22 January 2022 (UTC)[reply]

@Tks4Fish: yes, I find that agreeable. I will use the time between now and Feb 7 to write and test the code for the block importing bot, but I will not run it broadly until then (or sooner, if this discussion comes to a conclusion sooner). Thanks for the constructive suggestion. Huji (talk) 20:50, 22 January 2022 (UTC)[reply]

I'm not a huge fan of diluting the term “global”, to be honest. The reasoning is weak, too. A local community could neither decide to remove the stewards' ability to assign local user rights on every wiki. Seems like an issue to be taken to WMF what they consider stewards to be. Best, —DerHexer (Talk) 22:09, 22 January 2022 (UTC)[reply]

I share sDrewth's concerns and I've just asked WMF to give its opinion about the matter. --Vituzzu (talk) 22:09, 23 January 2022 (UTC)[reply]
  • I also would like to hear WMF's opinion, specially regarding the risk of privacy violation involving this change. Global block exemptions are many times discussed by stewards using private information. How is that going to be handled locally? I feel that we are creating a bigger problem instead of working on a simpler solution. This is the first time I am aware of that issue with block exemption on fawiki and believe we can come up with easier solutions. For instance, creating a better communication with local checkusers before approving exemption from users from fawiki or even other interested projects.—Teles «Talk ˱C L @ S˲» 22:45, 23 January 2022 (UTC)[reply]
    Your idea sounds like a much better solution. Letting a wiki opt-out of GIPBE seems like a significant overreaction. Legoktm (talk) 07:21, 24 January 2022 (UTC)[reply]
    @Teles: the point about privately discussing the reasons for GIPBE is valid; however, note that any wiki can decide to imports all global blocks as local blocks too, in which case the user inevitably has to discuss their reasoning for getting local IPBE with local sysops/CUs of that wiki too. I don't think Meta can disallow that, can they?
    The point about having a better system for assigning GIPBE is one already raised at Requests for comment/Global IPBE guidelines. Aside from a user who is active on fawiki, I see no other supporters. I also don't see much involvement from Stewards in that RfC. I cannot see a path forward for this argument.
    I also don't see much of a path forward with the current request. I am keeping it open just for the sake of fawiki seeing a clearly written decision on it. Huji (talk) 21:15, 24 January 2022 (UTC)[reply]
    I see this as very problematic to put global rights on optout. Global rights are there and necessary for global work.
    In my opinion, a single local community cannot apply for optout because it works within the global community. 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 18:04, 29 January 2022 (UTC)[reply]
@Tks4Fish: given the above conversation, is there any response from Stewards on this matter, and should I proceed with enabling my block-importer bot? Huji (talk) 23:42, 7 February 2022 (UTC)[reply]

Deletion of Draft:List of sex symbols[edit]

Status:    In progress

Can you delete this article? It has more than 5,000 revisions and can't be deleted by a regular administrator. Thank you. --Liz (talk) 23:29, 15 March 2022 (UTC)[reply]

Context: the reason for deletion is w:WP:CSD#G13 as the page had no human edits since September 2021 other than those relating to this deletion debacle. * Pppery * it has begun 23:35, 15 March 2022 (UTC)[reply]
Note that there was some copy-paste moving in this edit that may require that the draft-space article remain in order to comply with the attribution requirements of CC-BY. There may need to be some sort of history merge (which I don't claim to understand); or perhaps the simplest approach would be to 1) move Draft:List of sex symbols to article space; then 2) change it to redirect to Sex symbol in article space, thus preserving its edit history (and associated talk page) to meet CC-BY requirements. Probably fully-protect it, then, too, to prevent it from being hijacked back into an article. TJRC (talk) 01:14, 16 March 2022 (UTC)[reply]
That would not be an appropriate redirect since there is no such list at the target article, nor should there be one. Nor should the page be kept since the draft namespace is [...] not for the indefinite hosting of material that is unsuitable for inclusion in the article mainspace and the last serious attempt to resolve the reasons that lead to the article's deletion was in July 2020. * Pppery * it has begun 03:30, 16 March 2022 (UTC)[reply]
Relevant history of the merged content:
Luigifan adds a section on Video Games in 2007
219.95.159.164 adds Lara Croft in 2007
Kevin j adds a mention of Betty Bloop in 2007
76.27.215.219 adds Jessica Rabbit in 2007
Enric Naval reorganizes the video games section in 2008. At this point all copyrightable content related to Lara Croft that survives in the current version of Sex symbol has been written.
PeaceNT expands the cartoons section in 2008.
Curb Chain rewrote the bit about Betty Bloop to its current form in 2011
Jessica Rabbit was removed during a cull in 2011 and then re-added with more detail by 201.87.47.172 (w:Special:Diff/456708756) and Beyond My Ken (w:Special:Diff/456791278) in October 2011.
Curb Chain rewrote the bit about Jessica Rabbit to its current form in 2012
I believe the above should provide sufficient attribution for the copy-paste-moved content and allow this draft to be deleted without creating undesirable relics (remember: Attribution does not require blame), even if the diff links (which I provided to allow others to check my work) break when the draft is deleted. TJRC, do you agree? * Pppery * it has begun 04:16, 16 March 2022 (UTC)[reply]
I think the normal way to preserve page histories for attribution when a redirect isn't possible is through a talk space page, like en:Talk:Bengal famine of 1943/attribution; what say you @Pppery, Liz, and TJRC:? Whatever it is, though we need to resolve the issue here - the page's been tagged for deletion for several days already. Jo-Jo Eumerus (talk, contributions) 10:21, 18 March 2022 (UTC)[reply]
w:Wikipedia:Merge and delete#Record authorship and delete history is an accepted method of providing attribution, and there's no good reason to retain 10,000 revisions of junk in order to provide attribution for a three-sentence addition involving around ten of them. * Pppery * it has begun 14:20, 18 March 2022 (UTC)[reply]
I don't have a whole to to add: looks like both of the approaches above can meet the requirements of CC-BY without retaining the list, so I'm good with that. (Just to clarify, I'm certainly not trying to steathily retain the list in history; I'd always argued for its deletion.) TJRC (talk) 23:35, 18 March 2022 (UTC)[reply]

Help with adding Auto-Citation in my Home Wikipedia[edit]

Status:    In progress

I have been redirected here by one of you stewardess or whatever you call the role of a Wikimedian.

Please go here--> https://tl.wikipedia.org/wiki/Usapang_Wikipedia:Kapihan#Coming_soon

A bit of summary: I wanted to add an auto-cite in Visual Editor of Wikipedia Tagalog similar to that of English Wikipedia. Since I am not in control of the functionality and the codes of Wikipedia, can someone add it in our Wiki please? I can help in the translation and formatting and some admins too. Please ping me for immediate reply. --Likhasik (talk) 06:33, 16 March 2022 (UTC)[reply]

(non-steward comment) @Likhasik: I'm pretty sure that this is not in stewards/global sysops/interface editors' scope. However, I think I know what you're looking for. The extension is called Citoid, and to install it locally, please see the installation manual. I'm unfamiliar with it, so sorry that I can't provide a step-by-step guideline. NguoiDungKhongDinhDanh 07:06, 16 March 2022 (UTC)[reply]

bigdelete enwiki Huge userpage[edit]

Status:    On hold

Need someone to delete w:User:NickBerlin87. User page seems to be a continuation of an older version of w:Template:COVID-19 pandemic data, which was changed to a different way of updating that the editor disagrees with; see w:Template talk:COVID-19 pandemic data/Archive 18. Drmies (talk) 21:36, 16 March 2022 (UTC)[reply]

While I agree that what NickBerlin87 is doing is pointless, I don't see what speedy deletion criterion it meets (U5 doesn't apply since the user has too many edits to pages outside their own userspace). * Pppery * it has begun 21:47, 16 March 2022 (UTC)[reply]
@Drmies this seems like something that should get discussed at w:en:WP:MFD first. — xaosflux Talk 14:24, 18 March 2022 (UTC)[reply]
w:en:Wikipedia:Miscellany for deletion/User:NickBerlin87 is open, so this should be held pending conclusion there. — xaosflux Talk 14:56, 18 March 2022 (UTC)[reply]

OAuth permissions[edit]

Symbol comment vote.svg Preferably permission requests should be submitted using the form from Special:OAuthConsumerRegistration.

After submitting this form, you will receive a token that your application will use to identify itself to MediaWiki. An OAuth administrator will need to approve your application before it can be authorized by other users. It is possible to request approval using {{oauthapprequest}}, please create a sub-section to this part.

A few recommendations and remarks:

  • Try to use as few grants as possible. Avoid grants that are not actually needed now.
  • Versions are of the form "major.minor.release" (the last two being optional) and increase as grant changes are needed.
  • Please provide a public RSA key (in PEM format) if possible; otherwise a (less secure) secret token will have to be used.
  • Use the JSON restrictions field to limit access of this consumer to IP addresses in those CIDR ranges.
  • You can use a project ID to restrict the consumer to a single project on this site (use "*" for all projects).
  • The email address provided must match that of your account (which must have been confirmed).

See also[edit]

Cooperation requests for: comments (local) (global) · translation

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Steward_requests/Miscellaneous&oldid=23018834"