Duh, thanks!

@Andrawaag - FYI, I've basically proposed the same thing for Sunday morning: T229281.

Probably at some point, yes. We should take screenshots of all the views, though, and upload them to Commons so the info that isn't available through wikistats isn't lost entirely.

This is a problem with the Javascript tools, you probably want to open a separate ticket for that.

I created a new ticket here: T229593

Following from the general switch to using the sitelinks for Commons over the last year...

@Mike_Peel - Could you explain this sentence? What is the "general switch"?

I made a simple user script for Commons that allows you to import iNaturalist images from within a Commons category or gallery page (whichever one is associated with the Wikidata item for the taxon). To use it, add the following to your common.js page:

mw.loader.load( '//commons.wikimedia.org/w/index.php?title=User:Kaldari/inat2commons.js&action=raw&ctype=text/javascript' );

Then clear your browser cache and go to a Commons category or gallery page (for example, https://commons.wikimedia.org/wiki/Category:Synemosyna_formica). If there's an "iNaturalist Import" button by the page title, you can click it and it will load all the free-license iNaturalist images for that taxon (up to a certain amount). Let me know what bugs you find (pun intended).

@iamjessklein, @Esanders - What do you think about the idea of retiring the "Switch to VE/Wikitext" dialog entirely?

@Tpt - Can you update the production code to incorporate the fix? (or add Sam as a maintainer so he can update it.)

@Nuria - Yes, that's the main feature I would be interested in: being able to combine variables (for example, all content pages created by anonymous users) instead of having to choose just one or the other. That would be a welcome addition!

That interface is more limited, but I suppose it will do. Thanks.

@Ottomata - Thanks for investigating! I don't really care where the data lives, I just need a publicly-accessible way to monitor page creation trends. This dashboard was doing a great job of that, so I would be happy if it could be resurrected. If not, we just need something equivalent set up elsewhere (but publicly assessable).

I've been hitting this problem consistently with the Massviews tool (only using 1 tab). I wonder if slightly tweaking the 10ms pause would fix it. Maybe we could try changing it to 12ms and see if that makes the difference, as currently we're surfing right on the edge of the throttle.

@dbarratt - Another reason it may not make sense to store the ipblock IP addresses in the actor table is that, at some point, the actor table may no longer be used to store IP addresses due to IP masking. However, we will always need the ability to store IP addresses in the ipblocks table, regardless of IP masking. Thus the semantic difference could end up being a practical difference at some point in the future.

The previous breakage task for reference: T201420

@kaldari thanks for that background knowledge. This makes sense and would be fine, however is not consistently the case at the moment as it seems to time out after 30 days after creation and not even necessarily 30 days in the queue.

Looks like you're right. I stand corrected.

@Niharika, @Mooeypoo - Note that at one point there was a cron-jobbed maintenance script (updatePageTriageQueue.php) running on the production servers that automatically removed any pages from the pagetriage_page table (i.e. the "queue") if they had been marked as reviewed and were at least 30 days old. If that maintenance script is still running, it will need to be modified to take these exceptions into account, i.e. pages which have been added back to the queue manually. You'll also need to figure out what you want to do with them in the long run. Should they also expire from the queue again at some point?

@Barkeep49 - FYI, the curation toolbar was never available on any page. It was available on pages that had been in the Page Curation queue within the past 30 days (even if they had already been reviewed). This link is still in the Tools menu for such pages (AFAIK). Look for "Open Page Curation" in the menu.

Of the 3 options, "Reimplement with OOjs UI" is the best, IMO. Showing the videos in Media Viewer is overkill since most of our videos are small and don't come close to filling the screen, same for open in new tab. "Enlarge the video in page" will reek havoc with article layout. If you're going to fall back to a pop-up anyway (in cases where there isn't room for expanding), why not just keep it simple and use a pop-up by default? If I remember correctly, the old player had a config variable for setting the pop-up threshold (vs. just playing the thumbnail version). Seems like that would be good to implement as well.

@Niharika - Perhaps Anti-Harassment could pick this up, as they'e done a lot of work related to blocking lately.

@dbarratt - When I try to submit the form on the web interface, I get "Error authenticating. Resetting. Please try again." Is that related to the callback issue?

@dbarratt - I've added you as a maintainer to the citations and citations-dev tool forge projects. All testing should be done in citations-dev and then once it's running smoothly, the code can be moved to the main citations tool as well. Web interface for citations-dev: https://tools.wmflabs.org/citations-dev/

A volunteer dev started working on this recently. Their pull request is at https://github.com/ms609/citation-bot/pull/1624. A good starting point would be to review the patch and see how far they got.

Oh yeah, the community really wants Citation bot to stop doing user-activated edits as Citation bot. In fact they've debated blocking the bot because of it.

@Mooeypoo - I've updated the acceptance criteria to address your concerns.

I was thinking that we not only authenticate with OAuth but also use the OAuth credentials to make the actual edit as well (similar to how IABot's user activated edits work). That way blocked users would be blocked from making the edits automatically and we would always be able to prove who made a particular Citation bot edit (and it couldn't be denied as spoofing).

Sadly, my flight was cancelled and I wasn't able to find another flight in time so I won't be making it to the Hackathon. Good luck to everyone else!

@Krenair - The actual uploading is handled by urluploader, but UploadWizard has to do a lot of communicating with Flickr's API beforehand for information. Is there some kind of proxy API it should be using for that?

Works now! Thanks!!

@Bawolff - What is now the correct way to import images to Commons from 3rd party websites on the client-side? For example, when I currently try to import images from Flickr using UploadWizard, I get the following error:

[Report Only] Refused to connect to 'https://api.flickr.com/services/rest/?&format=json&nojsoncallback=1&method=flickr.photos.licenses.getInfo' because it violates the following Content Security Policy directive: "default-src 'self' data: blob: https://upload.wikimedia.org meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikivoyage.org *.mediawiki.org wikimedia.org". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.

Should we add api.flickr.com to the CSP or does UploadWizard need to be refactored somehow?

Tried logging in again from an incognito tab, but still just get 401s for all the actual content. And if I try to go directly to any of the content URLs like https://superset.wikimedia.org/superset/recent_activity/154/?limit=50, it says "access denied".

Thanks Nuria! I can log in now, but when I do I get a bunch of 401 errors and nothing loads besides the header (regardless of which tab I click on). Not sure if that's just me or how it is for everyone.

@Volker_E - Thanks!

Thanks for your work on this, @Krinkle!

Any chance this can be fixed before the Hackathon (a week from now)?