Template talk:Unblock reviewed

This template was considered for deletion on 11 August 2023. The result of the discussion was "keep".

Untitled

Hey -- I have some concerns about this process. It seemed like a good idea at first, but when is the {{unblock reviewed}} tag supposed to be removed? If never, the category will just fill up endlessly. I would put a {{adminbacklog}} tag on Category:Reviewed requests for unblock, but I'm not sure what we're supposed to do about it. Any thoughts? Mango juice^talk 16:09, 19 July 2006 (UTC)[reply]

The category is not necessarily meant to be easy to maintain, it exists mainly to make Category:Requests for unblock much easier to manage, but also to preserve a record of why someone had their request knocked back, and to allow for other admins to come and review blocks. See old discussion here and here.

It can probably be safely removed when the person is unblocked (because the template only carries information about a block in progress), or if they want to withdraw it, or (if they are blocked indefinitely) when some nice person prunes it. --bainer (talk) 17:38, 19 July 2006 (UTC)[reply]

Sensible. I've added a note to the bottom saying the template should be removed when the block expires, or after 2 days. That way, if the tags are removed when they should be, the category won't be full of irrelevant, stale unblock requests. Mango juice^talk 18:05, 19 July 2006 (UTC)[reply]

the "NO REASON GIVEN" text

Is there a way to get that to show up if the reviewed reason is blank? I'm not that good with wiki code so I am curious. Anomo 13:15, 7 September 2006 (UTC)[reply]

I'm not sure what you mean; if there is no reason given for the unblock request, "no reason given" will show up. If you want to leave that blank while filling in a decline reason, you can do "{{unblock reviewed|2=[decline reason]}}". Mango juice^talk 14:48, 7 September 2006 (UTC)[reply]

I think it might use the #if statement. I don't know if there's an else statement there. I will have to look it up. The way it is, probably a blank one would hit the whatever kind of else statement mediawiki has and then say no decline reason given. Anomo 23:20, 7 September 2006 (UTC)[reply]

Category deleted

It was decided at CFD to delete Category:Reviewed requests for unblock which this template put pages into, since no one was maintaining it. Discussion is here. the wub "?!" 12:38, 7 October 2006 (UTC)[reply]

What constitutes abuse?

What exactly consitutes abuse of the unblock-review template? Is there a maximum number of times it can be used, or a minimum period between uses? Or is it at admins' discretion? --Mel Etitis (Talk) 17:37, 16 February 2007 (UTC)[reply]

Are you asking about abuse of this template ({{Unblock reviewed}}) or the reminder about abuse of the template usually used first, {{Unblock}}? See Template talk:Unblock for the current discussion about lack of documentation of those rules. (SEWilco 18:27, 16 February 2007 (UTC))[reply]

PAGENAMEE vs BASEPAGENAMEE

{{editprotected}} This template currently uses {{PAGENAMEE}} instead of {{BASEPAGENAMEE}}. This causes problems in archives such as User talk:82.148.97.69/Archive 1, where the "block log" link points to [1] instead of [2]. Could an admin please replace all instances of {{PAGENAMEE}} with {{BASEPAGENAMEE}} in this template? —Remember the dot ^(talk) 21:04, 7 April 2007 (UTC)[reply]

It seems to me that the right thing to do is to use this code:

which substitutes the page name when the template is placed. This makes sense since the template it only meant to be substituted. CMummert · talk 01:25, 8 April 2007 (UTC)[reply]

That would work too, as long as users remembered to substitute the template. But it should be {{<includeonly>subst:</includeonly>PAGENAMEE}} because we're using it to form URIs and PAGENAMEE is how you get a URI-friendly string. You might want to read meta:Help:Variable, which talks about this. —Remember the dot ^(talk) 03:09, 8 April 2007 (UTC)[reply]

It looks like this template is often not substituted, based on the backlinks. I'll change it to BASEPAGENAMEE for now. It seems to me that the ideal solution would be for this template to be auto-substitutted by a bot, like other templates are. I thought it was standard to substitute every user talk page template - hmm. CMummert · talk 11:50, 8 April 2007 (UTC)[reply]

I made the change, but I don't really like it. It only fixes the problem for single-level archives. I would much rather see a substituted template. CMummert · talk 12:02, 8 April 2007 (UTC)[reply]

Some templates on talk pages are not substituted, and for good reason. Templates such as Template:ISP and Template:SharedIPEDU are boilerplate notices that are not substituted so that any improvements to the wording of the template show up on the talk pages. This is probably one of the reasons why there is no bot to mindlessly subst all templates on talk pages. —Remember the dot ^(talk) 19:31, 9 April 2007 (UTC)[reply]

Why remove?

"This template should be removed when the block has expired, or after 2 days in the case of blocks of 1 week or longer."

Why?

From what I can gather, this line is a reference to the fact that the template used to put pages in Category:Reviewed requests for unblock, but as that doesn't happen anymore, I think this line can be removed outright. Am I correct, or am I missing something? EVula // talk // ☯ // 18:09, 9 April 2007 (UTC)[reply]

Hm.. I think you're correct, so I removed it. There's really no point to removing these now. Mango juice^talk 20:39, 2 July 2007 (UTC)[reply]

Edit request

Could an admin please add <noinclude>{{pp-semi-template}}</noinclude> to to the top so people no its Semi Protected, it wont let me edit it because even though my account is older than four days it has cascading protection enabled on it, thank you.Telly addict 15:37, 19 April 2007 (UTC)[reply]

Done. EVula // talk // ☯ // 15:59, 19 April 2007 (UTC)[reply]

Visible?

Look people, it's simply misleading to use that word here. Of course the template is "visible"; nearly all our templates are visible and they don't require pedantically pointing that fact out. Instead, the usage here strongly implies the template actually adds the user's page to a list somewhere, which is probably historically what this sentence actually meant. I'd be happy with wording less misleading, like "This template remains present" but I'm not sure what that even means. -- Kendrick7^talk 20:58, 19 November 2007 (UTC)[reply]

Personally I never thought this sentence could be misunderstood, why not "This template must not be removed"? -- lucasbfr ^talk 21:29, 19 November 2007 (UTC)[reply]

I see no problem with that statement, and making a category would be fairly futile, because the cat would be hundreds deep and unnavigable. --Jeffrey O. Gustafson - Shazaam! - <*> 21:31, 19 November 2007 (UTC)[reply]

I agree that a category is impossible. I'm terribly sorry for screwing up IRC or what have you, I should have checked the links. I never kept up on who won the subst wars, but I suppose in this case at least bots don't clean up and delink from the active template.
Anyway, if the statement on visibility isn't intending to be confusing, it certain doesn't actually add anything. -- Kendrick7^talk 21:57, 19 November 2007 (UTC)[reply]

I think the statement should be removed, it's misleading. It's technically true (and yes, one can even search for them by following "what links here" from Template:Unblock reviewed) but I don't think it's right to deliberately confuse people. I also don't think we should have instructions saying to add a new {{unblock}} template for further review: they'll figure that out themselves, plus WP:BEANS applies. I do want to note that a category should definitely NOT be created; there was one before but it got deleted: (CfD). Mango juice^talk 15:24, 20 November 2007 (UTC)[reply]

OK, and that category deletion postdates this wording; see [3]. So that was clearly what "visible" meant at one time, that the template put the talk page in that category. Per Mango, I'll remove the wording again. -- Kendrick7^talk 23:14, 5 December 2007 (UTC)[reply]

maximum of two per year?

I was looking at the current wording "maximum of two" and thinking that as so many bans are of indefinite duration, we should be considering some allowance for periodic re-applications for unblock. If I'm indef blocked tomorrow, do I use one right away, and wait ten years and cross my fingers? And maybe make the final request on my deathbed so I can die as an editor in good standing? I was thinking "two per year" would strike a reasonable balance. Thoughts? -- Kendrick7^talk 22:26, 18 December 2007 (UTC)[reply]

OK, added this. -- Kendrick7^talk 07:44, 23 December 2007 (UTC)[reply]

Heya, just noticed the change. It's a good point. One problem: suppose somebody gets four short blocks in a year; would appealing each of those blocks once take them over the limit? Granted, the prior version didn't mention any factor of time, so that same ambiguity would still have been present, anyway. Shifted it to "per block or per year," since that seems to get a slightly more specific message across without being too wordy. – Luna Santin (talk) 21:33, 24 December 2007 (UTC)[reply]

Good thought. I tweaked it slightly. -- Kendrick7^talk 23:18, 24 December 2007 (UTC)[reply]

Interwiki

{{editprotected}}

Please add [[ro:Format:Deblocare revizuită]] in the interwiki list. Thank you. Daniel Message 15:24, 20 September 2008 (UTC)[reply]

Done Rjd0060 (talk) 01:30, 27 September 2008 (UTC)[reply]

Background color

I'd like to change the background color of this template, so that it's easier to discern between open and reviewed unblock requests. Something like

Examples

Currently: You are using this template in the wrong namespace. Use this template on your talk page instead.
1: You are using this template in the wrong namespace. Use this template on your talk page instead.
2: You are using this template in the wrong namespace. Use this template on your talk page instead.
3: You are using this template in the wrong namespace. Use this template on your talk page instead.
4: You are using this template in the wrong namespace. Use this template on your talk page instead.

I don't particularly care which color. I'd rather not use the light pink color, since that's too closely associated with warnings. And since it tends to be a big template, some very light color is probably best.
Opinions? Amalthea 10:25, 18 May 2009 (UTC)[reply]

Any but the yellow backgrounded ones. Chillum 14:10, 18 May 2009 (UTC)[reply]

Whichever one you thought of first, per WP:DEW Gurch (talk) 14:53, 18 May 2009 (UTC)[reply]

Hehe, I didn't know WP:DEW, but was sure that if I just changed it at my whim people would show up to complain, as lame as it might be. Anyway, I've now changed it to some random color != before. Thanks, Amalthea 15:19, 18 May 2009 (UTC)[reply]

I didn't know either, but I changed it before thinking (sorry about that). The barbie pink doesn't suit a decline very well ;). Note that {{Unblock-un reviewed}}, {{Unblock-auto reviewed}} need to be changed accordingly too. I was not bothered by the blue personally (you differentiate them at first glance already). I think we should go towards a color not matching a speedy, and maybe orangeish (like the block templates?). -- Luk ^talk 09:32, 20 May 2009 (UTC)[reply]

Sure, I don't mind, as I said I only want them to have a different look compared with active ones. I changed the two you mentioned to match this one. Cheers, Amalthea 10:53, 20 May 2009 (UTC)[reply]

Extra space

{{editprotected|Template:Unblock reviewed}} There is a space before the last ) in the string of links. –BuickCentury Driver 20:23, 30 May 2009 (UTC)[reply]

Done. -- zzuuzz ^(talk) 20:27, 30 May 2009 (UTC)[reply]

Proposed edit

Please replace this code:

{{#if:{{{2|{{{decline|<noinclude>non-empty</noinclude>}}}}}}|<hr/>Decline reason: "{{{2|{{{decline}}}}}}"|}}

With this code:

{{#if:{{{2|{{{decline|{{{declined|{{{reviewed|{{{review|<noinclude>non-empty</noinclude>}}}}}}}}}}}}}}}|<hr/>Decline reason: "{{{2|{{{decline|{{{declined|{{{reviewed|{{{review}}}}}}}}}}}}}}}"|}}

I request this as there have been instances in the past where admins have used things like 'declined' or 'reviewed' in place of what the template suggests, such as here. I'm sure there are others out there, this modification would fix any such potential, or standing, errors.— Dæ dαlus^Contribs 11:35, 7 January 2010 (UTC)[reply]

I would disagree with this request. It generally makes things more complicated, rather than simpler, when you allow a multitude of alternative parameters for one purpose. It is preferable for admins to learn the correct usage of the template. — Martin (MSGJ · talk) 12:39, 7 January 2010 (UTC)[reply]

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. - Rjd0060 (talk) 14:51, 7 January 2010 (UTC)[reply]

I join MSGJ in opposing the change in the template. This would expand the wiki-code of the template and make it harder to read. I don't find it hard to remember 'unblock reviewed' and 'decline='. For a truly helpful reform, try to find a way to set things up that the 'Whatlinkshere' to this template won't expand ad infinitum. (See Mangojuice's comment at top of this page). EdJohnston (talk) 02:05, 11 January 2010 (UTC)[reply]

Old template was good, just change the word "Abuse" to "Misuse".

This blocked user (block log | active blocks | autoblocks | unblock | contribs | deleted contribs | abuse log) has asked to be unblocked, but an administrator has reviewed and declined this request. Other administrators may also review this block, but should not override the decision without good reason (see the blocking policy). Do not remove this unblock request while you are blocked.

Request reason: "Please state the reason which accompanied the respective unblock request."

Decline reason: "{{{decline}}}"

If you want to make any further unblock requests, please read our guide to appealing blocks first and then use the {{unblock}} template again. Note that misuse of this template may result in your talk page being protected.

Furthermore, the current template says for the remainder of the block. That implies that the block will never be "indefinite" status. That should probably be removed. mechamind 9 0 20:35, 9 February 2010 (UTC)[reply]

If not, then this should be changed.

{{edit protected}} Remove "for the duration of your block" from the lower line. Some blocks are indefinite. mechamind 9 0 01:48, 27 March 2010 (UTC)[reply]

This still applies. Anyone abusing their talk page can lose their talk page rights, regardless of the block length. Hersfold ^(t/a/c) 04:44, 27 March 2010 (UTC)[reply]

Losing talk page privs has nothing to do with the block notice. -- Avi (talk) 00:23, 31 August 2010 (UTC)[reply]

Indef blocks and template removal

There is no reason for an indef blocked user, or especially a banned user, who still has talk page rights, not to remove the template. The reason remains in the history and we should not be "scarlet lettering" people for punitive reasons. For a temporary block, it makes more sense, IMO. If someone abuses the template (repeated unblock requests) then indef or not, they lose their talkpage privs, and the note can remain. -- Avi (talk) 00:30, 31 August 2010 (UTC)[reply]

Since indefinite ≠ permanent, theoretically, all blocks are temporary. If there is consensus to allow indef blocked or banned users to remove the template, then by all means, we should change the wording. —DoRD (talk) 00:48, 31 August 2010 (UTC)[reply]

Oh, I now see that you've already changed it. —DoRD (talk) 01:00, 31 August 2010 (UTC)[reply]

Undone; let's shmooz. -- Avi (talk) 01:08, 31 August 2010 (UTC)[reply]

Sorry for scattering it everywhere. :) Certainly we don't want to scarlet letter anyone, well most anyone. I'm not sure how it should be handled in cases of banned users, but I don't think that garden variety vandals should be allowed to remove the template. —DoRD (talk) 01:17, 31 August 2010 (UTC)[reply]

Agreed, but banned/indefblocked users with little hope of an unblock for the next n months should not have to have that as a badge of shame. Howver, if there is a sequence of socks and abuse, it may be necessary to keep it on the page for future reference. I'm fine with it being handled on a case-by-case basis, but the way it is now there is no option for an indefblocked/banned user to remove it. -- Avi (talk) 03:05, 31 August 2010 (UTC)[reply]

Requested change

{{editprotected}}The text Do not remove this unblock review while you are blocked. needs to be made bold, like it was on the previous layout/version of this template.— Dæ dαlus^Contribs 06:23, 18 November 2010 (UTC)[reply]

Why bold? It screams. I was trying to get rid of the overuse of bold. — Edokter • Talk • 13:15, 18 November 2010 (UTC)[reply]

I have partially reverted, per WP:BRD. Although the changes to Template:Unblock were thoroughly discussed, this sentence is unique to this template and so wasn't included in the discussion. However I would say that I am sympathetic to Edokter's attempts to clean up these templates and remove excess formatting. — Martin (MSGJ · talk) 13:48, 18 November 2010 (UTC)[reply]

Would italics be a good compromise? — Edokter • Talk • 14:20, 18 November 2010 (UTC)[reply]

It's important that the text Daedalus mentions is bold, because if the user repeatedly removes declined unblock request, h* may end up getting h*s talk page access removed. Hey Mid (contributions) 16:18, 18 November 2010 (UTC)[reply]

As Hey has said, it's needed for this version of the template, as it is not something that should be looked over. The bold is meant to grab attention that would otherwise be missed, to prevent a user from thinking they can do opposite of what the bold says.— Dæ dαlus^Contribs 21:59, 18 November 2010 (UTC)[reply]

An "X" is way too bitey.

I say use an Exclamation Mark instead. mechamind 9 0 22:22, 17 November 2010 (UTC)[reply]

I disagree. The X is the generic block icon, and appropriate since the blockee remains blocked. — Edokter • Talk • 17:42, 18 November 2010 (UTC)[reply]

On a lighter note

{{editprotected}} The "has" at the beginning of the message should probably be "has had". The current case contains a grammatical error. mechamind 9 0 22:34, 17 November 2010 (UTC)[reply]

Done, thanks --Step hen 23:02, 17 November 2010 (UTC)[reply]

"our" guide to appealing blocks

{{editrequested}}

I think "the guide to appealing blocks" generally is considered to be a more neutral wording than "our guide to appealing blocks". Also, the link to "administrator" should be Wikipedia:Administrators. Also, WP:GAB should be changed to Wikipedia:Guide to appealing blocks. Thanks in advance. Hey Mid (contributions) 15:50, 18 November 2010 (UTC)[reply]

Done. — Edokter • Talk • 16:17, 18 November 2010 (UTC)[reply]

"...who declined the request"

I'm not sure whether it's correct to say "who declined the request". As the request is about this one, I think it should be "who declined this request", as the user may make more than simply one unblock request during his/her block. Maybe the whole first sentence should be copyedited to say "This unblock request by this blocked user has been reviewed by an administrator, who declined this request." Eventually, there should also be an {{{administrator}}} parameter so that it may say "...has been reviewed by administrator [username]", if the administrator parameter is specified. Hey Mid (contributions) 13:31, 19 November 2010 (UTC)[reply]

The sentence alredy contains "This request". Using "this" twice just feels like bad English. But there is always room or improvement. How about: An administrator has reviewed and declined this blocked user's unblock request. — Edokter • Talk • 14:07, 19 November 2010 (UTC)[reply]

In both cases (except for my proposed sentence) the word "this" grammatically points at the specific user, not "this unblock request". There are always some issues after implementation of a new style. But I agree that in English it is weird to write "this" two times in the same sentence. In your proposed sentence you're basically shifting in the current sentence, so instead of starting with "this blocked user's unblock request", you start with the administrator part. That is also weird. The most important part is that it is an unblock request, so that comes IMO first, the administrator part comes second. Hey Mid (contributions) 14:25, 19 November 2010 (UTC)[reply]

Using this would be bad english. the is correct in this instance. No need to change anything. -DJSasso (talk) 19:11, 19 November 2010 (UTC)[reply]

Broken link

The "blocking policy" part is wiki-linked to an outdated subsection in Wikipedia:Blocking policy, which is no longer there. I therefore suggest removing that subsection part in the wiki-link and instead simply link to Wikipedia:Blocking policy. However, is there a corresponding part or subsection in the current blocking policy context? Hey Mid (contribs) 12:21, 1 January 2011 (UTC)[reply]

Done — Edokter • Talk — 13:32, 1 January 2011 (UTC)[reply]

Use in archives

Can anyone fix the template so it works correctly in archives, such as User talk:MickMacNee/Archive/2010? I tried replacing PAGENAME with BASEPAGENAME, but that didn't go all the way back to the user.--SarekOfVulcan (talk) 19:12, 13 June 2011 (UTC)[reply]

That proves harder then I though... #titleparts: seemed to be the solution, but it replaces underscores (added by PAGENAMEE to keep links whole) with spaces, destroying the links again. — Edokter (talk) — 19:35, 13 June 2011 (UTC)[reply]

Edit request from StormContent 10:04 AM EDT

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

It has been a long time since the icon in the template is used. Could it be changed please? Replace with . Thanks. StormContent (talk) 14:12, 24 July 2011 (UTC)[reply]

Why? — Edokter (talk) — 16:30, 24 July 2011 (UTC)[reply]

Because how long the current icon stayed on for? 3 years. I like to make it a little more up-to-date (and better) with the icon that will be replaced for futher use of the template.

Here's an example.

{{unblock reviewed | 1=Comment below | decline=See the octagon on the top-left? I'm replacing the ordinary Octagon X with the new X icon because what if everyone thinks of this: "This unblock template looks fine with us, but after such a long time of usage of the icon in the template, it may be a little boring, so we make changes to unblock reviewed and add a new icon to make this template newer."? So, is it OK with you or no? StormContent (talk) 20:36, 24 July 2011 (UTC) }}[reply]

I happen to like the old icon, and I doubt 'boring' is a ground for changing it. The current icon fits the box quite nicely. Design changes need consensus, so I'm disabling the request. — Edokter (talk) — 21:53, 24 July 2011 (UTC)[reply]

Telling users to use {{unblock}} again when inappropriate

I've come across a few situations where community sanctioned, or ArbCom/WP:AE restricted editors use {{unblock}} when it's inappropriate. They get told read the relevant policy (which says, on another page, not to use {{unblock}}), but the {{unblock reviewed}} template on their page by default implies that they can use it again.

As a concrete suggestion could a switch be added to {{unblock reviewed}} to change the message at the bottom of the box to say: "If you want to make any further unblock requests, please read the guide to appealing blocks." Rather than "If you want to make any further unblock requests, please read the guide to appealing blocks first and then use the {{unblock}} template again. If you make too many unconvincing or disruptive unblock requests, you may be prevented from editing this page for as long as you are blocked."

This would help reduce confusion and stop editors who are panicking from having their talk page access revoked--Cailil ^talk 15:49, 26 August 2013 (UTC)[reply]

Fix needed

The template breaks when an unblock request is accepted. Can somebody see what's happening and fix it? See User_talk:SoapFan12#October_2013 for an example. — ΛΧΣ²¹ 16:13, 20 October 2013 (UTC)[reply]

Fixed on userpage; erronous ":" was used. Would have happened on decline as well. — Edokter (talk) — 18:06, 20 October 2013 (UTC)[reply]

Thanks. WOuld have done it myself but I'm not a sysop. Cheers. — ΛΧΣ²¹ 05:54, 21 October 2013 (UTC)[reply]

You could have; the user page is not protected. — Edokter (talk) — 17:02, 21 October 2013 (UTC)[reply]

Link needs to be updated

The link to the autoblock finder needs to be updated to https://tools.wmflabs.org/xtools/autoblock/index.php. I'd do it myself but will more likely than not mess something up. Cheers,--Jezebel'sPonyo ^{bons mots} 20:38, 17 January 2014 (UTC)[reply]

Protected edit request on 10 May 2014

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Replace

[//tools.wmflabs.org/xtools/autoblock/?u={{BASEPAGENAMEE}} autoblocks]

with

[//tools.wmflabs.org/xtools/autoblock/?user={{BASEPAGENAMEE}} autoblocks]

Otherwise the autoblock check will take you to the "X!'s Tools" form without submitting a check directly.
See old code vs. new code. Meteor_sandwich_yum (talk) 13:40, 10 May 2014 (UTC)[reply]

Done. — Edokter (talk) — 14:09, 10 May 2014 (UTC)[reply]

Background color

Currently the background color of the template is not showing up on the mobile version of our site. Could anyone take a look a this and hopefully fix it? Tvx1 (talk) 04:37, 17 January 2015 (UTC)[reply]

Typo (braces and bracket in wrong order)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

There is a minor typo in the template, similar to this one. The template does work as-is, but depends on some unusual behavior of template parsing which could very well change at some point. Basically, the template only works by accident currently, so I think the typo should be fixed. I have fixed the other templates similar to this one with the same typo (presumably copy-pasted from the original) but since this one is template protected, I cannot fix it. --Khgtcv (talk) 00:24, 11 June 2015 (UTC)[reply]

Done - good catch. Alakzi (talk) 00:38, 11 June 2015 (UTC)[reply]

Template-protected edit request on 12 November 2015

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The sentence at the bottom of this template containing what is on the order of a parenthetic expression needs a second comma. The comma should be inserted after the bolded word "first". I've applied the requested changes to the sandbox of this template. —Godsy^(TALK_CONT) 23:47, 12 November 2015 (UTC)[reply]

Done (comma serves also as "and"). Be prosperous! Paine 02:32, 13 November 2015 (UTC)[reply]

Another option for procedurals

I'd like another option besides "decline" and "accept", for procedural declines; or maybe another template like "unblock closed". (Users are not supposed to delete declines, but there's no reason not to delete the procedural ones.) And glancing at a page full of procedural declines gives perhaps a more negative impression than necessary. Does this make any sense? --jpgordon^{𝄢𝄆 𝄐𝄇} 04:36, 2 June 2017 (UTC)[reply]

Requested move 29 November 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: Nominator withdrawn (non-admin closure). B dash (talk) 02:43, 30 November 2018 (UTC)[reply]

Template:Unblock reviewed → Template:Unblock declined – The word "reviewed" is ambiguous, because after the admin reviewed someone's unblock request, they can either accepted or declined the request. B dash (talk) 07:01, 29 November 2018 (UTC)[reply]

Support Although "Unblock reviewed" would probably be slightly more likely to refer to a declined one, I certainly wouldn't assume that. The proposed title is clear, while this one isn't. Note that there is also {{Unblock on hold}} for those that haven't been accepted or declined. Crouch, Swale (talk) 07:04, 29 November 2018 (UTC)[reply]
Oppose Per zzuuzz. Crouch, Swale (talk) 17:42, 29 November 2018 (UTC)[reply]
Oppose. Am I reading this nomination right? Despite what's displayed on the template page, it's used for both accepting and declining requests (example accept). And if you look at the section above, there might also be other options. I'd accept there are some slight semantic issues, for example it's not the unblock that's being reviewed, but the proposed move doesn't really deal with any of that (and nor should it). Any ambiguity regarding the result of the review seems appropriate. -- zzuuzz ^(talk) 08:38, 29 November 2018 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Requested addition

I'd like see added the checkuser link, same as on the unblock template. I'd do it myself, but I'm not all that good with spans and such to get the link sizes right. It would save a step or two when I want to check on an already declined unblock. It's additional clutter, but only for us checkusers. --jpgordon^{𝄢𝄆 𝄐𝄇} 16:37, 4 April 2019 (UTC)[reply]

Done I've made the links the same as {{unblock}}. — JJMC89 (T·C) 02:48, 5 April 2019 (UTC)[reply]

Yay thanks!! (wow, never saw {{hidden ping}} before!) --jpgordon^{𝄢𝄆 𝄐𝄇} 05:12, 5 April 2019 (UTC)[reply]

Clock icons

This template currently uses File:Orologio verde.svg and File:Orologio rosso.svg, which are licensed with an attribution-required license, but doesn't link to the source page at Wikimedia Commons as required. There are CC0 versions of these icons which don't require any attribution or link at File:Appointment green.svg and File:Appointment red.svg. Any objections to switching this template (as well as Template:Unblock-un reviewed and Template:Unblock-auto reviewed) over to the slightly different public-domain versions of those icons? --Ahecht (TALK
PAGE) 15:40, 14 September 2019 (UTC)[reply]

Done since there were no objections after a week. --Ahecht (TALK
PAGE) 01:32, 23 September 2019 (UTC)[reply]

{{unblock}}: Creating an "idletimestamp" parameter

See Template talk:Unblock#Creating an "idletimestamp" parameter. ~ ToBeFree (talk) 23:05, 12 April 2020 (UTC)[reply]

Add a feature?

Right now, we've got only "approve" and "decline". But I'd like to have a third option, for procedural declines. The most common situation I'd want it for is "This IP/account isn't blocked". I consider it unpleasant to decline an unblock request, and it's certainly unpleasant to have such a request declined, but of course it's the most common response to unblock requests. It would be nice to deal with "procedural declines" with out having to say "NO". (Maybe I'm too sensitive, I dunno.) --jpgordon^{𝄢𝄆 𝄐𝄇} 04:36, 24 June 2020 (UTC)[reply]

Accepted unblocks

When the template is used on an "accept" unblock, it leaves standard verbiage "If you want to make any further unblock requests..." Why would an unblocked user want to make further unblock requests? Are we inviting editors to further "misbehave" so they can be blocked and unblocked again? Is there a way to have different verbiage at the end of the template depending on whether or not the unblock request is declined or accepted? Thanks! 78.26 _{(spin me / revolutions)} 23:58, 10 May 2021 (UTC)[reply]

Can this be fixed?

There's something that happens on Template:Unblock reviewed that doesn't happen on Template:unblock. Specifically, if there's an indentation colon before the request, the formatting gets messed up. I can't show an example on this page because the unblock reviewed template won't let me use it on this page! You can take a look at it in action here. Maybe there's a premature div ending or something? Anyway, you can test it simply by putting a : as the first thing in the source to this template. --jpgordon^{𝄢𝄆𝄐𝄇} 06:05, 14 January 2022 (UTC)[reply]

It would have helped if you had given an example or put something on the testcases page, but I have tidied the template a bit. Did it help? If not, provide an example here inside <pre>...</pre> tags. If necessary, you are welcome to post a sample on my talk page. – Jonesey95 (talk) 05:19, 17 February 2022 (UTC)[reply]

The testcase looks like the colon (:) wraps the first div into dl and dt tags, which are for description lists. The div is immediately closed, so the box around the template is closed prematurely. On mediawiki the colon is documented to use dl and dt. In my personal opinion, I think the template itself should give the user an indent parameter (and internally use padding/margin to indent it), but there is also an bug phab:T6521 where people belive the colon should not output this syntax. There is not an phab ticket about this specific issue, but T6521 is related.--Snævar (talk) 08:00, 17 February 2022 (UTC)[reply]

It's a long-standing problem with the MediaWiki software that attempting to use external indentation on a box that contains a list will screw the layout. But why would you want to indent it? --Redrose64 🌹 (talk) 09:05, 17 February 2022 (UTC)[reply]

I think I see the question now: Jpgordon, do you mean that when someone puts a colon before the entire template, it causes problems? Yes, it does. Many templates that start with div tags do not like to be indented. The {{Unblock}} template tolerates a preceding div tag because its content starts with a set of span tags, , which is indented, followed on a new line by the first div tag. We could do something like that in this template as a workaround if it made sense for this template to have an id associated with it. – Jonesey95 (talk) 14:57, 17 February 2022 (UTC)[reply]

Exactly that. So {{unblock}} looks just fine even with the colons are there, so the requesting user doesn't see anything wrong, but then when one of us modifies it to {{unblock reviewed}} (often with an automated tool which bypasses source editing completely), it looks like crap, rather confusingly I'd think to a naive user. --jpgordon^{𝄢𝄆𝄐𝄇} 15:03, 17 February 2022 (UTC)[reply]

Waking up this one a little bit. If indeed, putting in a  would make the problem go away, can we do it please? Are span ids in short supply?

Here's the workflow on this, by the way; the problem has become much more common with the advent of the reply tool. 1) User gets blocked. Admin puts up a proper signed block notice. A "reply" link is inserted. 2) User uses the "reply" tool to request unblock. The problem begins, as reply indents the request. Problem, however, is invisible to the user, since {{unblock}} has that span-id thing. 3) Admin then uses the unblock-review tool, which creates {{unblock reviewed}}. 4) Admin then has to go back and edit the user talk page again to get rid of the unnecessary indentation.

There are several ways this could be fixed. The reply tool could refrain from indenting certain classes of replies (maybe there are others that shouldn't be indented?). But there's resistance to putting any context sensitivity there. The reply tool could have an option to to be inserted in some context (like block messages). But I think "reply" is useful for, well, replying to blocks. The unblock-review tool could put a newline in front of the inserted template. Or this template could include that span thing. But I have no idea what _that_ might break. --jpgordon^{𝄢𝄆𝄐𝄇} 04:44, 13 September 2022 (UTC)[reply]

Possible syntax issue?

I have recently noticed that the note regarding further unblock requests and revocation of TPA that appears at the bottom of the template has somehow inexplicably disappeared? Text in question is as follows:

If you want to make any further unblock requests, please read the guide to appealing blocks first, then use the {{unblock}} template again. If you make too many unconvincing or disruptive unblock requests, you may be prevented from editing this page until your block has expired.

The diff of the edit that removed such text is [4] with ES "remove autoblock link as it does not function". The code for the text in question is still there in the current diff, so I suspect there may be a syntax error that causes it to not appear at the bottom of the div. Could someone please investigate and fix? --DL6443 (^Talk/_Contribs) 22:10, 14 March 2022 (UTC)[reply]

Point of order. After digging a little bit further it seems like the message is erroneously displaying after a request is accepted rather than declined. A similar enquiry was posted by admin User:78.26 around 10 months ago but it seems like nothing had advanced further since then. If I remember correctly after an unblock request is accepted what should be displayed is a message to the unblocking administrator regarding autoblocks, which was removed due to the link not working. After digging a little more it seems like the removal of said message broke the template so that the "decline" verbiage moved to the display when the request is accepted, leaving nothing to be displayed when a request is declined. Could someone please fix? --DL6443 (^Talk/_Contribs) 22:22, 14 March 2022 (UTC)[reply]

@DL6443: This edit removed a message with a malfunctioning autoblock link, and it also removed the pipe character that was acting as the else in an if. I've placed null text in for accepts (and a comment about what was there), so the text should show up on declines again. —C.Fred (talk) 01:42, 15 March 2022 (UTC)[reply]

Noted. Thanks DL6443 (^Talk/_Contribs) 01:44, 15 March 2022 (UTC)[reply]

"Do not remove"

I'd like to suggest that the Do not remove this unblock review while you are blocked notice be moved from the top to the bottom of the box. My rationale is that the top section otherwise is a notice to other users and admins: This blocked user's unblock request has been reviewed by an administrator, who declined the request. Other administrators may also review this block, but should not override the decision without good reason (see the blocking policy); while the bottom section is instructions for the blocked user: If you want to make any further unblock requests, please read the guide to appealing blocks first, then use the unblock template again. If you make too many unconvincing or disruptive unblock requests, you may be prevented from editing this page until your block has expired. I think it would make it more visible to the affected user. --jpgordon^{𝄢𝄆𝄐𝄇} 18:02, 2 April 2022 (UTC)[reply]

Template-protected edit request on 2 August 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Remove "blocked" from "This blocked user's unblock request..." as it is redundant since it mentions it's an unblock request. foo bar baz 09:24, 2 August 2023 (UTC)

Makes sense, especially since it sometime needs to be used with non-blocked user. Do we need a link to "blocking policy" somewhere else? --jpgordon^{𝄢𝄆𝄐𝄇} 13:40, 2 August 2023 (UTC)[reply]

Oh, we already have a link to blocking policy in the thing. I've also moved the "do not remove" message to the end, as someone -- oh, me! -- suggested a while back. --jpgordon^{𝄢𝄆𝄐𝄇} 13:44, 2 August 2023 (UTC)[reply]

Request to slightly change one of the sentences in the template

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I have seen a number of blocked users trying to modify their declined unblocked requests - some of the most recent ones being this edit and this edit. Such edits can be disruptive. Hence, I would like to suggest that the Do not remove this unblock review while you are blocked notice be changed to Do not remove or modify this unblock review while you are blocked instead. That way, edits such as those I linked at the start of my request are less likely to happen again. SG5536B (talk) 01:06, 20 January 2024 (UTC)[reply]

Adding the template edit request notice to see if an administrator would like to implement this change. To me, at least, this seems like a good and helpful change. 2600:6C50:37F:6BBF:7402:A946:A86F:946A (talk) 11:23, 21 April 2024 (UTC)[reply]

Actually, thinking about this more thoroughly, I'd instead suggest adding a separate phrase regarding the "do not modify" aspect. Keeping them in the same sentence might be unclear, since a user might think that it would be fine to modify the declined unblock request after they are unblocked, which is basically redundant. I would say, add the phrase "please do not modify this declined unblock request." to the first sentence so that the message reads "If you want to make any further unblock requests, please do not modify this declined unblock request." Then, I'd say have the following phrase standalone as its own sentence, perhaps removing the word "please" to avoid repetition. 2600:6C50:37F:6BBF:7402:A946:A86F:946A (talk) 11:33, 21 April 2024 (UTC)[reply]

Not done for now: I don't see any issue with the request itself (it's reasonable) but let's get a consensus on how we want to word it before changing things. Cross-posting to other noticeboards to garner more discussion might be helpful. Primefac (talk) 11:40, 23 April 2024 (UTC)[reply]