Thanks!

(I'll look at this in a second if you don't get there first.)

(Just clarifying the title since I thought "write protection" might mean something like makeEphemeral().)

Yep, this is correct. Context is that there's no difference today between 'r' and 'w' connections. Distinguishing between them (primarily so we can send some reads to a replica) has always been a theoretical far-future goal, and I think we're mostly consistent about connection use in practice, so this piece hasn't been built yet. Building it would make eventual replica reads easier.

Can you try restarting apache (or php-fpm) and see if that resolves this issue?

Turns out these are type-by-type, so yell if you see more and I'll just close this sooner or later if nothing turns up.

Oh, sure, that makes sense. So maybe not "valuable indefinitely", just "valuable until Diviner can extract symbols from a bunch of languages".

I actually can't reproduce this immediately now, either.

D13277 touches on another case for this which I hadn't considered in T6823: code blocks in Diviner articles. That one feels pretty relatively strong/compelling to me.

At this point, I'd guess this is probably something real dumb like us rendering the text forms of these wrong.

I wouldn't expect this to have changed that -- see T4345.

In Wikimedia it occasionally happens that we do things in private ... but usually the fact that we're working on something in private isn't private in itself

I suspect it may not make sense to totally merge them -- particularly, I think the "pipe CTAGS into some script" sort of use case is valuable indefinitely.

(It sounds like @lpriestley helped you resolve this specific issue.)

It looks like these have required you to type in monograms/object names (not acted as typeaheads) since late 2013, when they were last touched (D7823). Their behavior doesn't seem to have changed, and still seems to work fine.

This now works, and the upstream has implementations for the reasonable-seeming use cases we've seen, particularly the policy that blocks T8488. This is relatively modular and extensible, but I don't think there are any other problems for it to solve right now.

Assuming this is a misfire on "wiki", not an actual Wikimedia request.

This got raised to "Normal" so we could brand Phacility on admin.phacility.com

I think that there should be a separate visibility policy for the description page of a space.

Oh, and on these cases:

The rest of Spaces is on more solid ground, now, so I'd like to keep working on a path forward here.

I think this isn't a very good use case for batch editing. This is an unusual administrative operation and probably best accomplished in other ways.

Development Log

@Krenair, maybe you just don't have your preferences configured on this install in the way you expect? From the logs, it looks like you were sent mail with links in it:

Awesome! Let us know if you run into anything.

(I can't reproduce this, don't see any queries missing keys in the query plan, and haven't seen reports from other installs, so this isn't an upstream priority.)

And:

Sorry, we don't offer support for writing custom extensions or applications. See T5447.

I'm unable to reproduce this problem. We routinely run daemons for long periods of time without issues. See:

Let me write up a guide on how to use the performance tools and we can start there.

This seems to have resolved itself (after I pushed?) so I now have zero repros. Assuming I am just insane.

Both the UI and function of these transactions should be fixed at HEAD.

This is intentional: batch operations are just a more convenient way to apply normal operations to a large number of tasks. They respect policies, trigger Herald, create transactions, generate email and notifications, and cause other effects.

One issue I hadn't thought about with using T5681 for this is that (without further changes) we'd have to create a new custom Policy object for every private thread, and they'd each be "different policies" with their own PHIDs. This would be OK for the most part, but feels a little icky.

@20after4, D13252 changes the signature of two methods in PhabricatorPolicyRule:

It will be possible to define this rule locally after T5681, but I don't anticipate bringing it upstream.

Presuming this is resolved since we found a reasonable explanation for the case above. Let me know if anyone is still seeing issues.

Maybe -- it's linked for me, and I would expect it to be linked for you because you have access to the space:

This was fixed by rP9c82881c, which is slightly ahead of you.

We want this for T8488 and it's probably a component in moving T8434 forward.

Per T8498, you can now send mail to test-space-bugs@phabricator.com to create tasks directly in S2 (join Space Test Users first if you can't see it). T8514 is an example.

Ah, interesting. I'm glad to hear it's been working out (although I'm a little surprised!).

Yell if that doesn't actually fix things once it lands, but I'm pretty confident it's the issue.