This is also more "while I'm here", but there's no web UI way to void an invoice right now. It would be nice to have a "Void Invoice" button for staff instead of requiring database fiddling, since this comes up occasionally.

It would also be nice to figure out Phortune permissions better here since this is a good opportunity to vet everything.

Phortune has a fairly unique problem where we'd like a given Cart object (which corresponds to a cart, invoice, or receipt depending on context) to be visible to managers of the payment account ("John Doe") that is buying the items and also the merchant account ("Acme Corp") which is selling the items.

We don't want to let AcmeCorp see everything that John has purchased, only things John has purchased from AcmeCorp. More broadly, the ideal permissions model here is more granular than just "Staff/Seller" vs "Customer/Buyer". Phortune should, ideally, support a future marketplace where users have three separate roles: Staff, Merchant, Buyer.

For example, we may let developers sell applications in an "App Store" in the future. In this case, Phacility would be in a "Staff" role; the developer/seller ("AcmeAppDeveloperCorp") in a merchant role, and the buyer ("John-who-works-at-EngineeringCorp") in a customer role. AcmeCorp developing and selling an application to EngineeringCorp, and Phacility is taking a fair and reasonable 99% cut or whatever.

This use case may or may not really come to pass, but it would be desirable to retain this role separation to support it and not just say "anyone with merchant access can see everything".

Currently, Phortune partially accomplishes this with grantAuthority()/getAuthority(). This mechanism allows particular pages to grant a viewer a particular authority (here, authority over a Merchant account) and then policy checks can test if a given viewer has a particular authority.

I'm not thrilled with this mechanism, originally from D11945. This mechanism is doing two things:

• serving as a cache, so we don't need to keep pulling merchant memberships for users multiple times on the same page; and
• allowing workflows to actively bestow authority on particular users.

The cache part is sort of fine, but it would probably be better for this to just be an explicit cache backed by PhabricatorCaches::getRequestCache() that can be cleared via destroyRequestCache(). The "Authority" change came before the "Request Cache" change (in D13153), and daemons may not properly reset the cache on user objects today. This is very unlikely to cause any real problems, but it would generally be more robust to have all the caching go through the same APIs.

The "workflows proactively apply grants at the Controller level" part is actively bad, since it breaks the idea that Query classes can just do all policy enforcement correctly and means that if you're loading Cart objects or other similar objects, you must first do a secret grantAuthority() dance or you get the wrong result. You always get the wrong result in the better direction (i.e., the application forbids you from seeing an object you should be able to see, which is annoying but not dangerous), but it's still the wrong result.

This likely led to some issues like T13341, where TransactionEditor does not know it has to do grantAuthority() magic. It also leads to a case where loading Account handles fails even if the viewer has Merchant-derived authority to see them, which is cumbersome and vaguely frustrating from a staff perspective.

The desired behavior is that the policy check encodes this behavior instead:

• You can see a Cart if you CAN_VIEW the associated Payment Account or CAN_EDIT the associated Merchant Account.
• You can see a Payment Account if you're a member, or the Payment Account has at least one cart or subscription with a merchant you CAN_EDIT.

Since none of these objects have mutable policies (or are ever likely to have them), we can implement this behavior in hasAutomaticCapability() and refine it (if necessary) with PhabricatorPolicyCodexInterface. If objects could have mutable policies, we'd possibly want to use PhabricatorExtendedPolicyInterface instead, but it can not currently express OR constraints (like "you must satisfy the object policies, and also be able to see either object X or object Y"). But I can't imagine ever letting a Cart have "Visible To: only me" policy and forbidding other payment account managers or merchant managers from seeing the object, so this is pretty moot.

Carts already implement the behavior described above mostly-properly. Some sub-objects do not implement the best possible / most robust policies, but these are easy to fix.

Accounts are really the only problem. Implementing the right behavior is fairly easy, but implementing it efficiently is trickier. In particular:

1. There's no cheap (mostly: O(number-of-merchants) instead of O(number-of-interactions)) way to get the set of merchants an account has interacted with (has one Cart or Subscription for).
2. There's no cheap (mostly: cache-friendly) way to get the set of merchants an account CAN_EDIT.
3. There's no trivial method for testing if sets (1) and (2) intersect.

To solve (1), we can write a "Payment Account X bought something from Merchant Y" edge when a cart or subscription is created, and migrate historical carts and subscriptions. We can reasonably pull and attach these edges in the Query unconditionally.

To solve (2) and (3), we can issue the query easily enough, but the policy layer will do a whole lot of checks/queries against it by default. We probably do still want something that looks a bit like getAuthority() from a cache perspective, but likely uses PhabricatorCaches::getRequestCache() instead of the weird, one-off Authority mechanism.

Then there are probably some minor cases where we want behavioral differences at the application level if a viewer is acting on behalf of a merchant vs an actual member of the payment account, but that probably does not need to be a policy-level test.

I think we end up with this approach:

• Add a "PaymentAccountHasInteractedWithMerchantAccount" edge.
• Write this edge when creating a "Subscription" or "Cart".
• Load and attach this edge in "PaymentAccountQuery".

Then, make viewer merchants cheap to test and do the correct test:

• Provide a PhortuneMerchantCanEditCache::canTheseViewersEditAnyOfTheseMerchants($viewer_phids, $merchant_phids) sort of API backed by the request cache.
  • It's probably fine to satisfy this by pulling all merchants the viewers can edit, since this is currently straightforward and we can anticipate that it is cheap.
• In hasAutomaticCapability(), do this test instead of the existing test.

Then, sort out downstream policies, how the Controllers handle policies, maybe add PolicyCodex implementations where necessary, etc.

Stuff to fix with subscriptions:

• Policies could use an update.
• Policies should use the new cache.
• No transactions yet.
• "Manage Autopay" has a read MFA upgrade gate, should be a transaction-based write one-shot MFA gate.
• "Manage Autopay" into adding a card is wonky. Should probably do "add card", then redirect you to confirm you want to set it as the autopay option.
• Subscriptions have inconsistent icons (blank calendar vs reload arrows).