D20808 fixes the two original cases (Harbormaster and Legalpad). There are probably more fields or actions which could be configured to be sometimes-unavailable, but these are probably the major ones.

This still needs another transaction type for installations/uninstallations; diff coming soon.

@amckinley Let me know if you need more to go on than the description above or get stuck anywhere.

The db001 issue is still an issue, but the shard has managed to stay just under 80% for the last couple of weeks so we're not in any immediate peril. As followups, I think T12217 and T12218 better capture the broader issues here.

I fixed it, I cannot be mean.

ayep

Have fun

I think I set home to just me on meta

From the home page, you can uninstall Home like this:

No idea how @swisspol found a link to Home to uninstall.

I deployed that change here (secure.phabricator.com). I'll cherry-pick it and deploy it on admin in a little bit, if nothing catches on explosion fire.

Haha, no worries. Uninstalling Home is pretty unusual.

ugh. sorry

After purging dead instances, db003 and db004 are each <25% utilized on their data volumes.

Purging db001 brought primary volume down to 79.2%, which is technically below the 80% caution threshold. It doesn't need to be fixed immediately, but the pathway forward isn't terribly clear. Some options are:

Instance service windows on db003 and db004 have synchronized and the shards are now purging.

The temporary directory storage pressure on repo016 has an unclear root cause (it's related to importing an SVN repository, but I haven't been able to pinpoint where the issue started). The issue no longer appears to be occurring so I'm going to stop digging until it happens again.

The storage pressure on db001 is primarily because an instance imported a large SVN repository with approximately 60M paths. The instance is a free instance with one user.

The db001, db003 and db004 shards have also hit 80% full on their primary volumes. I'm purging dead instances from db001 now. db003 and db004 have never been purged and need to have instance out-of-service dates synchronized first. This is currently underway for db004.

I'm going to move forward with the deploy since this shouldn't impact actual instances, the stuff in this menu isn't super-critical, and workarounds (albeit inconvenient ones) exist to access the items.

I think most of these are just moving into Application configuration over time, which tends to be a bit easier to use. I expect to just continue that trend in the future and this probably isn't worth building separately. I can't recall too much other confusion, and most of these are called <appname>.stuff anyway, which is fairly not-misleading.

In most cases, edits in Phabricator are preserved and displayed in a transaction log, similar to the one you are looking at right now on this task, where this very comment appears. The transaction log records a complete record of changes so it's easy to review what changed and when.

These are sort of technically visible in Config → Settings History, by looking at changes to phabricator.application-settings. However, this is mixed in with all the other settings and the actual diff is pretty hard to read (includes all adjusted settings; has raw JSON).