Org Web Adapter

Editing pages/mmpy_158_update_account_is_active_workflow.org

:PROPERTIES:
:ID:       9d1ebb4e-0dcd-4220-8666-39c75d560900
:END:
#+title: MMPY-158 Update account is active workflow

- source :: https://multimediallc.atlassian.net/browse/MMPY-158
- tags :: [[id:4b532967-a1d9-45f4-b1f0-9a02ad540ff0][Falcon Nest Project Story]] [[id:7c3bbb4e-d079-42c4-992c-3e76210911f4][Falcon Nest Project]]

* Tasks
** DONE Look into latest account is not activating for Helene in test :work:bug:mmpy158:qa:
:PROPERTIES:
:ID:       0fea79e2-bd41-d712-0f96-c0e57e4aad4d
:END:
<2025-06-12 Thu>

At first glance, it appears Helene was expecting the latest account to be
active, but the current work flow is explicitly the earliert account. Need to
check in on that.

- Note taken on [2025-06-12 Thu 09:41]

I think this is a flaw in the original implementation of account activation.
  Unless the June 4 account is closed, the check we do is for the earliest open
  account. So you’d need the June 4 account to be closed before the June 11
  account would become the active one. We should think through why the current
  implementation is for the earliest account. I can’t make total sense of it,
  but it seems to have been very deliberate, so was probably for reasons
  grinning face with smiling eyes
** DONE Follow up on account not activating for Helene :work:bug:mmpy158:qa:
:PROPERTIES:
:ID:       50b31a73-c930-e8b2-055e-7cc33cd5e7b1
:END:
<2025-06-12 Thu 11:00>
** DONE Open a PR to push account activation below the status save :work:bug:mmpy158:
:PROPERTIES:
:ID:       dba5077f-b48c-7f29-bc62-b84a4a94ee6f
:END:

- Note taken on [2025-06-12 Thu 12:58]

This was resolved in commit 4c7bc2b765c788fc4e703ad12d9baac1cb87a05e

<2025-06-12 Thu 13:00>
** DONE Open a PR to make the best account use the latest, not the earliest :work:bug:mmpy158:
:PROPERTIES:
:ID:       c86d8905-85bc-1510-bc08-aba071bf6bd0
:END:
<2025-06-12 Thu 13:30>

- Note taken on [2025-06-12 Thu 12:59]

Mostly we just need to flip the `created_at` order by. But I bet tests will
  need to be fixed too.

** DONE Once GCP is back up, figure out why tests are failling on both PRs :work:chore:mmpy158:pullrequest:
:PROPERTIES:
:ID:       d60b0000-f650-bdfe-6e90-2ee102322d32
:END:
<2025-06-12 Thu>
** DONE Fix breaking test around NewRelic logging :work:chore:tests:devdayslost:
:PROPERTIES:
:ID:       8b6e0967-adce-2a65-0418-3a40644ff74f
:END:

* Background

A user can have multiple accounts that are in good standing (i.e. open), but
when we make a payout, we need to know which is “active”. This is especially
important if there are multiple payees on an account.

In the first phase, we are going to keep this limited, just allowing a user to
add a payout method (or payee and payout method) and that newest one will be
marked active. At a later phase, the user will be able to select/switch/set
active accounts (possibly by date). Active could also be thought of as “default”
… but that word doesn’t have the same connotation of “this will be used next
time you get paid”.

Currently, the setting for active is conflicting with status changes and related
hold removals.

* Requirements

** GIVEN

A user creates an account

** WHEN

The account is marked open

** THEN

If the account is the most recently created, it should be marked as “active” &
“No active payout account” hold should be removed.

* Requirements
** GIVEN

A user completes the Stripe connect workflow (or any future workflow that moves
an account to open)

** WHEN

The account is then marked open

** THEN

If the account is the most recently created, it should be marked as “active” & “No active payout account” hold should be removed.