I don't see an obvious way to do this, so I'm asking: https://github.com/apollographql/apollo-server/issues/1839

I propose that we add this for 1.32+

Added a work-around to the project description. Since this work-around works (but is clunky), then I think it should be allowed within Wikidata.

I'm going to mark this task as resolved since this now has its own project board here: GraphQL

@Marostegui was the falloever to eqiad completed?

@TBolliger What would you like this to be updated to?

In T206499#4651171, @Aklapper wrote:

Stupid question: If this is hosted on https://graphql.wmflabs.org/ (not tools.wmflabs.org) then why is the source under "labs/tools/graphql"?

This request is to create a project to expand T173214 since the tool (in a basic form) now exists.

I would recommend mounting a volume rather than mounting to the host as that should resolve your problem. I don't think this is a problem with this container, but feel free to open this issue back up if there's something that should be changed in this container.

That is already happening:
https://github.com/wikimedia/mediawiki-docker/blob/master/stable/Dockerfile#L32-L33

In T206163#4640648, @dmaza wrote:

Whatever is decided here, multiblock should be kept in mind when designing it considering that something very similar needs to be done if/when multiblocks is implemented

There's been some instances where I had a parameter that was another translated string, it seemed like a valid use case.

Dropping Anti-Harassment since this shouldn't be affected by partial blocks.

In T204151#4630965, @aezell wrote:

@Mooeypoo How do we get this assigned to the next SWAT deploy?

In T194585#4630774, @dbarratt wrote:

@Anomie while I was testing your patch, I found this bug T205895, it's not related to this task explicitly, but partial blocks do not work properly with your patch until we fix it.

Oh, no, I just wrote it wrong, but it is a bug, if it returns true (as in, you are blocked), but prevents() returns false then you'd get no error.

In T205895#4630853, @Anomie wrote:

If User::isBlockedFrom returns false then the check should always return an error.

I think you have something backwards in there. If User::isBlockedFrom returns false, doesn't that mean the user isn't blocked from the page and therefore it shouldn't return an error?