Org Web Adapter

Editing pages/mmpy_26_update_is_user_payable_to_not_create_holds.org

:PROPERTIES:
:ID:       03d9b4b2-4daf-44a9-8d25-751183a70d57
:END:
#+title: MMPY-26 Update is_user_payable to not create holds

- source :: https://multimediallc.atlassian.net/browse/MMPY-26
- epic :: [[id:88adb9ec-ab52-4d87-8625-6cf72d01612c][MMPY-198 Compliance Holds, Fraud Holds, and Banned Payees]]
- tags ::  [[id:4b532967-a1d9-45f4-b1f0-9a02ad540ff0][Falcon Nest Project Story]] [[id:7c3bbb4e-d079-42c4-992c-3e76210911f4][Falcon Nest Project]]
- status ::  [[id:4d41d978-e56f-45c1-88d1-e2c76510972e][Status - Complete]]

* Background

If we are trying to standardize on a set of checks for a user ... did you look
at the hold creation in is_user_payable in payout.utils? Should we unify this?

This is making me question the logic of my card a bit ... in my mind, I had the
flow, which is requested on this card: user created -> make holds -> user
completes necessary information -> holds removed

What is currently (prior to this PR) in the codebase is: User created -> request
payout -> we attempt to pay -> make holds -> user completes necessary
information -> holds removed -> payouts approved

The user would want to know if they're tax information is invalid, but that is
only relevant after they have created it, and we could rely on tax status.
Similarly with account status, in the case of stripe where the account starts in
a pending status, we rely on the account status to inform the user.

Looking to the future, when a user is created for CB, we will check if the
user's app is CB (or if the user's app requires new payee holds) and create a
new payee hold on create ... which we wouldn't want to jam into a payout
request, because we can do the work of clearing holds prior to payout requests.
I can't think of anything else that we would create holds for explicitly on user
creation.

All this to say, I have put us in the situation of asking us to build both belts
and suspenders. Probably not harmful to leave both in, but we should be
thoughtful about any diverging logic.

* DONE Remove all references to hold creation in is_user_payable :bug:holds:mmpy198:mmpy26:project:work:multimediallc:
:PROPERTIES:
:ID:       402ebac5-10de-4cc5-326d-3c2140adea59
:END:
* DONE Fix broken tests from the migration :bug:holds:mmpy198:mmpy26:work:project:mulimediallc:tests:
:PROPERTIES:
:ID:       f2a950c3-f707-e9ee-316e-a778ed19438c
:END:
* DONE Clean up PR issues :bug:holds:mmpy198:mmpy26:work:project:mulimediallc:tests:
:PROPERTIES:
:ID:       5063122b-828f-f3de-7da5-fa378faa5ab4
:END:
* DONE Get tests passing :bug:holds:mmpy198:mmpy26:work:project:mulimediallc:tests:
:PROPERTIES:
:ID:       a9445fe0-13f5-aa0c-cdc6-c6be182faafa
:END: