• Do we want to show an empty cell for block params when the type is 'unblock', or show a message (e.g. below)?
• Is the message "N/A" something which should be a translatable message?
  • (guessing yes, though surprisingly "N/A" is not already a message, so perhaps its bad form..?)
• Is using the message log-action-filter-block-reblock okay for reblocks (i.e. "Block modification")

In T368111#10183394, @JWheeler-WMF wrote:

Updated requirements:

• Remove the "Target" column
• Add a log "Type" with the fields "Blocked" and Unblocked." When row represents "Unblocked," the "Expired" column should show "N/A."

Per the description:

This task is just for including the menu item. No action needs to happen

this change is currently only cosmetic — should this be hidden behind a flag and/or marked to not be merged until follow-up is complete?

PR: Add getPlagiarismRecordsCount function, and show open case count

(rm community tech tag, will pick this up as a volunteer)

Things I've done:

• Ran toolforge envvars create DJANGO_SETTINGS_MODULE "backend.settings"
  • I have no idea why this is needed for this, as you're setting DJANGO_SETTINGS_MODULE, but...
• Changed ~/www/python/src/uwsgi.ini to comment out the line wsgi-file = backend/wsgi.py
  • This may have worked, but using app.py as the docs suggest just seemed simpler and maybe easier to debug!
• Created ~/www/python/src/app.py with the following content:

import os

File:Snorkeling at Lindquist beach - US Virgin Islands March 2021.webm

note to self: put this behind $wgEnableMultiBlocks

@JJMC89 I very quickly took a look when this came in (nb. I'm no longer overly familiar with how this works!) and saw:

Yes, this can be closed as done

In T368605#10130031, @JWheeler-WMF wrote:

@TheresNoTime it looks like this has been in development since July 9. Is there anything at this stage that's a blocker? How high of a priority is this bug?

Live on Meta

That's correct — thank you

Job ran (e.g.) — potential follow-up work on what the template should do

@sbassett are we able to deploy this to production in its current state? (per above)

CommunityRequests is now live on beta metawiki — ready to be enabled on production metawiki when permitted

[snipped]

Checking and fixing bad titles...
Processing page...
page 1726347 (Usuário(a):195.175.037.08) doesn't match self.
renaming 1726347 (2,'195.175.037.08') to (2,'195.175.37.8')
page 1726349 (Usuário(a):195.175.037.6) doesn't match self.
renaming 1726349 (2,'195.175.037.6') to (2,'195.175.37.6')
page 1726360 (Usuário(a):195.175.037.8) doesn't match self.
renaming 1726360 (2,'195.175.037.8') to (0,'T195546/User:195.175.37.8')
page 5121018 (F:_A_Todo_o_Gás) doesn't match self.
renaming 5121018 (0,'F:_A_Todo_o_Gás') to (0,'T195546/f:A_Todo_o_Gás')
Finished page... 4 of 5752906 rows updated

In T372444#10075918, @AntiCompositeNumber wrote:

Can we get this backported ASAP? Special:DeletedContributions is a critical administrative tool.

iirc we will need to wait until 1.43.0-wmf.20 to add CommunityRequests to the extension-list [ patch ]

All listed accounts are now (auto)confirmed

Grabbing task to begin process of creating patches for the beta cluster deployment, pending my above comment

In T365525#9998963, @sbassett wrote:

In T365525#9988592, @MusikAnimal wrote:

My question for you: If we (i.e. my manager) agree to accept all security risks, how likely if at all would it be to ship the extension with just translations, then we slowly add code to it over time? This would make the transition considerably easier, and allow us to address some issues we have now such as T370230: Migrate translations to Community Requests. When we have enough code moved over for the extension to run standalone, we can ask for a proper security review. Until then, we could have all code (other than the translations) behind a feature flag, which we will not enable until the security review is complete. How does that sound? I know this is highly unusual but I thought it was at least worth inquiring :)

So the extension would be deployed to wikimedia production, but only translations would be made available for it? e.g. anything in its i18n directory? If I'm understanding this correctly, that sounds fine. Keeping feature development on a separate, undeployed branch would probably be preferred to a wikimedia production feature flag, but I'm not sure if that would suit your development needs. Regardless, it sounds like we should place this review request into our backlog again, for now? Until we have a better sense of when most of the code will be ready for the extension?

Here's my thinking:

In T370242#10062702, @MusikAnimal wrote:

I think for the Wishlist, we won't use https://meta.wikimedia.org/wiki/Talk:Community_Wishlist/RC as that's specific to Community Tech. I've just moved that template to Talk:Community_Tech/RC and put it in-use at https://meta.wikimedia.org/wiki/Talk:Community_Tech.

https://meta.wikimedia.org/wiki/Talk:Community_Wishlist/RC is now repurposed for this task. So I think the only work left to do is have the bot add the template to the talk pages after a wish is created. @TheresNoTime Did you need any help there?

Reminds me of T354599: Make IP reputation available as a variable in AbuseFilter and some of the work that went into SFS scores in AbuseFilter (there was also work to include Spur data in SFS but :shrug: )

In T371399#10038817, @FNavas-foundation wrote:

new adds --

• User:Susannaanas
• User:Sdkb
• User:Sj
• User:Mike Peel

nb. using Special:RecentChangesLinked with the actual template (e.g. {{Special:RecentChangesLinked/Template:Community Wishlist/Talk|enhanced=1|hidebots=1|days=7|showlinkedto=1}}) seems to work pretty well too?

AC1/AC2 were issues caused by a different (now fixed) bug

this.validateForm() is firing before some/all promises are completed? this.wishtitle.length (and others) in validateForm are returning 0 when called in