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).

It would be nice to put a transaction layer in the UI to clean this up.

I also plan to let you add a setting to configure who can adjust settings, so you can make this more complicated and really sew confusion and dissent among your enemies in other departments.

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.

Applications have editable policies (in Applications → Maniphest → Configure → Edit Policies, for example) that let you set things like "who can use this application?" but they don't currently record a transaction record when they are changed, so there's no way to see who changed things or when they were changed. If an application setting goes crazy, you can't go review a convenient transaction log to see who changed it so you can ask them what's up.

Application configuration is stored in an unusual way: there are two Config settings (phabricator.application-settings and phabricator.uninstalled-applications) which can't be edited directly, and which the interface in the "Applications" application writes to. It works this way for a few reasons. Among these, the most legitimate one is that we always need this information on every page (e.g., to check which applications the user is allowed to see and interact with) and using Config for storage is efficient (Config is already always available on every page). This is why edits are technically visible in Config → Settings History.

To add a transaction log, we don't need to change how things are stored, or even how they're edited. In the long run, it would be nice to convert that to and really do this properly -- so, for example, you could configure applications via the API -- but we can address this immediate concern with a simpler change which moves us about halfway toward that future state without really doing anything hacky. For now, we can just introduce some no-op transactions which record and display the changes correctly but aren't actually responsible for applying them.

When the change is complete, editing an application policy like "Can Use Application" should generate a visible transaction record on the application page that looks like this:

epriestley changed the "Can Use Application" policy from "All Users" to "Secret Elite". • Mon, Aug 29, 2016

This should let you figure out who changed stuff, and when. Here's where it's going to go:

To actually make this change:

• Create a new database for the "Applications" application (it does not currently have one) and a new transaction table to store the transaction records.
• Write new Transaction support classes (Transaction, TransactionType, Query, Editor) to interact with the table.
• Write a "policy change" transaction type, and an "uninstall/reinstall" transaction type.
• Have the "Edit Application Policies" and "Uninstall / Reinstall" application apply these transactions.
• Change the UI to show the transaction record.

I'll fill in more details about how to accomplish these steps when we make it here.

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

Adding a new DB is very slightly tricky since you have to go add it to PhabricatorBuiltinPatchList.php, D16314 has the last one we added.

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