If we make the permission changes discussed elsewhere (T8033, I think?), this might just become something like a containerPHID which points at a Dashboard for panels created from dashboards, another Panel for panels embedded in panels, and null for standalone panels.

We don't plan to support this. Large installs often have hundreds or thousands of open revisions, so "build all open revisions" would trigger hundreds or thousands of builds for every push.

Thanks! This code has been churning recently (T12298 / T12217) and I likely broke this in D17389. I think I observed this behavior, but this report should save me a great deal of time hunting the bug down.

You can already use third-party externals that use namespaces, and we already bundle some (Twilio, Balanced until it was removed in D12074).

(You could also pipe the list into bin/remove destroy --force, equivalently.)

You can re-run the migration explicitly with:

Thanks. D17507 should fix this, and will un-stick any tasks stuck in queue.

Thanks! D17506 isn't the most elegant possible patch, but should fix this. Let us know if you're still seeing issues after that lands.

It is likely that the vulnerable code predates significant portions of the Files and permissions systems, and was just overlooked as these other systems upgraded and gained more powerful policy and permissions capabilities.

The fix is now available on master (rP7626ec0c) and stable (rP6f879559). I've upgraded this install without incident. Per above, note that upgrading destroys evidence, so you should plan any audit or response actions you want to take before upgrading.

T9789 has stabilized (the majority of major transaction types now run through ModularTransactions) although it didn't end up providing much clarity here. This is no longer blocked on anything, I just need to develop a specific technical plan to resolve the "adjust" vs "expand" sequence inside transaction application so the "expand" code has access to the old text by the time it runs.

The system described in this task became "ModularTransactions", which feel like they're in a good place.

That sounds reasonable to me. We remain open to more feedback here if it does turn up, but I think we don't have a clear set of next steps otherwise. Thanks for following up!

(D17404 is an earlier fix for a similar issue, but for self-auditors added via Herald.)

To move forward, we need complete reproduction instructions which we can follow to reproduce this issue in a clean environment. See Contributing Bug Reports and Providing Reproduction Steps.

@Taskle, if you're a Phacility SAAS customer can you ping me at support@phacility.com with your instance name? I can't immediately find it. We're working to formalize the SAAS/prioritization relationship a little better, but we can push more weight behind requests if they're coming from paying customers vs free self-installs.

This also has SAAS customer interest.

This got a mention in D17499, but when rendering a timeline we currently need two awards for each user who is going to get a full-sized profile image rendered.

My belief is that we've satisfied all the requirements for Translatewiki to move forward on their side.

We have SAAS customer interest in this too, now.

Go to Conduit on your install.

Phrequent is not installed on this server. Conduit only shows methods from installed applications.

Probably bump the version unconditionally now

(For example, if the goal was to very aggressively optimize for minimizing network traffic, we could read the entire repository history to figure out which refs were ancestors of other refs first? Then we could drop those and only ask for descendant refs. But this seems crazy, since it's saying that ~20 bytes of network traffic is more costly than like one hundred million disk I/O operations?)

it has to compare "What do I have" vs. "What do you have"

I think T12393 and this probably have a similar set of root causes.

Remarkup is cached, so you'll need to run bin/cache purge --purge-remarkup (or make an edit, or create a new post) to purge the cache.

To define 6 pages yourself: use a text panel, then link to 6 pages in the text. For example, you might use text like this:

The "Policy" task says "implement PolicyInterface", but the interface is already implemented so that Query works. The description should be adjusted to be more accurate.

Great, thanks for testing it! We'll upstream that and I'll file something to put a longer-term fix in place.

Old-school resigns, accepts, and rejects are still using edges directly (can we get rid of these completely?).

These pathways are still dodging ModularTransactions and thus not getting double writes after D17495:

Specifically, from the error, since X and Y are consistent in the error part and the fetch part, it appears that this process has lost a race to another process which is doing the same fetch.

(Presuming this is resolved since it's been open for a while without feedback.)

Feel free to file a new report if you are able to come up with clear, working reproduction steps that reproduce this issue on a clean install.

Some workarounds in the short term:

This is likely just some of the secure hosts having different configuration. Ideally, we'd get the rCORE deployment stuff aligned to deploy them with it.

We may eventually build this for T7413 but I don't think it's a good use of our time without a strong, narrow motivating use case like that.

This doesn't appear to be moving toward becoming an actionable report.

Any ideas on how we can move forward with this?

These CSS rules:

OK weird, I can't reproduce it anymore. Anyway, I'll add the response body from differential.querydiffs here. It shouldn't contain any sensitive information, but I'll restrict the visibility of the file given that it does contain email addresses.

rLOCATIONS now has two branches:

Bug reports need complete reproduction instructions and complete version information. See Contributing Bug Reports, Providing Reproduction Steps, and Providing Version Information.

Happy to accept a patch for this (deleting that one line of code) if someone wants to claim that they tested the scenario above and it worked correctly.

This behavior is not "incorrect", it just isn't the most human-readable format we could use. I'm going to merge this into T8973, which discusses this and other potential improvements to human-readability for JSON encoded for presentation.

T7413 is security/usage data.

After D17489 you should be able to do this: