In T381198#10383844, @Trizek-WMF wrote:

As I understand it, you want to move fa:ویکی‌پدیا:درخواست راهنمایی/Flow to fa:ویکی‌پدیا:درخواست راهنمایی. I want to make sure that you are not trying to revert the archiving process we applied to remove Flow from the wikis.

Thanks for this analysis. With this in mind, what is the next step? Should we add fawiki to $wmgFlowEnableOptInBetaFeature?

I am okay with being closed as dupe. It would be worth noticing here (and echoing in the other task) that the wikis involved where on two different server clusters (enwiki is on s1 and fawiki on s7). Shouldn't circuitbreaking issues only impact one server cluster?

I also think "start" and "end" is better than "inline-start" and "inline-end". After all, these are allowed values for the align parameter; align=center and align=start read well, and align=inline-start is too verbose with no real advantage.

I suspect CI is hitting a false positive here. The $wiki variable is effectively sanitized by the if/else statement above. That said, I'm not sure what the best path forward is.

Or it could be pivoted into a long format (one row for each property, as opposed to one column for each property).

@taavi any ideas?

In T299947#9537244, @Ladsgroup wrote:

@Huji Hi, the data has been fully populated for fawiki. If you want check and switch your tools and queries, it should be fine to do so now.

Thanks for the quick response! I will educate the user.

fawiki and I believe web replicas. Maybe this line will help you verify my answer.

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

1. Site should be able to determine if a user is a CIDR range or not

@Xqt any idea how it magically got fixed? And how to prevent it in future?

True. However, not all users need to see *all* public logs together, and what you proposed will end up running those expensive queries and merges *every time*. Most of the time, this would be wasteful.

Whomever fixes this, can you also kindly specify where the user_config settings for CI is stored? I cannot find it in https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/refs/heads/master/zuul/layout.yaml .. and nor should I, because it should involve a password or BotPassword of sorts, I guess?

No. The query finds all articles linking to a User or User_talk page, and distinguishes which has an "under construction" category. So the last part is optional, not mandatory. Your suggested query makes it mandatory.

Where in the code are these tables created? I don't recall the core code needing to create separate tables for elections. I know WMF has occasionally created tables (see ./cli/wm-scripts) but those are not for every single election either. And at least the present code (same link) only relates to 2022 and later.

Fully understand the reasoning behind this normalization. But (unexpectedly) this will result in some queries to run substantially slower. For instance:

In looking at the EXPLAIN results for those two queries, the first one runs more quickly not only because of denormalization, but also because the WHERE condition on pl_namespace uses the pl_namespace index on the pagelinks table. However, it seems like the secondary does *not* use the lt_namespace_title [[index]] on the linktargets table (where I expected it would be used as a partial index). Any ideas on how to improve my query or the indexes?

In T14019#9467421 I proposed existencelinks. I don't like page_dependencies because pages can depend on each other in ways other than an existence check.

@tstarling agreed, and I think the table should be called existencelinks and in addition to #ifexists from ParserFunctions, when the .exists feature from Lua is used, that should also generate a row in this table. Which means we should *not* move #ifexists to core; rather, we should create a new Special Page that allows searching this new table (I propose ParserFunctions should own this Special Page) and design the Special Page in an extendible way, such that existence checks via Lua modules could also be tracked.

Since other code (such as this in patrol.py) relies on isAnonymous() to indicate if the user is an anonymous *user* (as opposed to CIDR), we cannot extend isAnonymous() to also return True for CIDR ranges. Therefore, the correct solution is to create a new isCIDR() method.

Found the problem. To get the blocks for registered users, we can use API:Users, but for anonymous users, we cannot use that IP and we fetch the last block using API:Blocks instead. This relies on correctly determining that the user is an anonymous user.

In reviewing the code further, I understand this API endpoint is not supposed to be used for anonymous users at all.

@Xqt the change we applied above doesn't exactly work (anymore?)

And we should add some unit tests for this code too.

You are the best!

@nskaggs as of a few minutes ago, I have emptied my crontab which means my grid-based jobs will not be running anymore. All the jobs have been migrated to the toolforge job framework. I have run them once and it seems like they all worked fine. I will continue monitoring.

Coming back to this just to memorialize how things finally got to work.

@Ladsgroup any chance you could take this on?

Another observation: in Quarry, you could get a public link to your query and share it with others; in Superset, the "Copy link" feature doesn't seem to generate something that is publicly accessible.

I got here through the message at the top of Quarry. I really liked Superset's interface. The first issue that came to my attention: you need to know which server cluster your desired wiki is on. Quarry has the advantage that you specify the wiki schema name and it'll figure out which server to query. I wish Superset could do the same.

The most common form of invalid DB names returned are those ending with a semicolon. I created https://github.com/toolforge/quarry/pull/19 to address that issue specifically.

I think that was it.

The same could be said about the opposite (if you like it, create a gadget or user script to add it). Note that this link did not exist until a few weeks ago when the original patch was merged.

This just happened again for me.

What I meant is: the offset you choose in the UI could be relative, and the software would translate it to absolute time for you.

3. A log entry is generated each time the user looks at one page of results. The log entry message could be like $3, $1 got edits for <bdi>$2</bdi> (partial results)

In T311363#8030026, @Dreamy_Jazz wrote:

If T311375 is implemented this may make this less important. However, the way that would be implemented that I see would be basically some sort of offset. This offset could either be time based or ID based, but if this was time based then it would implement half of what this ticket is requesting (as it would be from arbitrary time X defined to end of period).

Between T311375 and T311363 I think this becomes nearly unnecessary and definitely not worth the effort. Decline?

I have found two strategies that would work for me. @JJMC89 and @taavi I would appreciate it if you could advise me as to which you think is best.

I cannot but @LordProfo can. I will send them a reminder on wiki as well.

Support. And what @Zabe said. FWIW, the patches on which @Dreamy_Jazz has reviewed show that they have a good grasp of what makes for good quality code, what makes for a good patch, and how to provide constructive feedback.

I have been thinking about this a lot in the last few days. I am sorry, @Ladsgroup but I think your change should be outright revert. I will create the patch.

In T32790#8018484, @Stang wrote:

Boldly close as I thought this problem no longer exist now.

Oh yeah, I get that. But fixing a regression should not be at the expense of cluttering another interface in ways that would not be helpful 99%+ of the time.

In T310947#8013504, @Ladsgroup wrote:

I originally thought about showing it if the user has cu rights but OTOH, you might need to check logs of a former CU, stewards who has done cu but not cu in that wiki anymore and so on. I know the chances are slim but not impossible.