Risk board
For Frontier staff. No technical knowledge needed. Updated 2026-10-27. Thomas keeps it current. The full engineering record is RISK-ASSESSMENT.md, under the same codes. Decisions mentioned here are on the Decision board, which also explains the words we use.
What this is
A risk is something that could go wrong with the new membership system (FMS). Each one has a code, such as FIN-3: FIN is billing, SEC is security, MIG is the move from the old system (PMPro), and OPS is running the servers.
| How serious | Means |
|---|---|
| Critical | Money could move wrongly, or member data could leak, with no limit |
| High | Wrong charges, many members cut off, or broken records, in a limited case |
| Medium | Support work or a fixable mix-up. No money lost |
| Low | Small, rare or cosmetic |
Each risk is Fixed, Partly fixed, Accepted (we know about it, and chose to live with it) or Open.
Who signs. Every risk has an owner, who keeps track of it and says what it would cost. When we choose to live with a risk instead of fixing it, the Business owner signs, in writing. This holds even when the risk is technical.
The picture today
| Area | Fixed | Partly fixed | Accepted | Open | Total |
|---|---|---|---|---|---|
| Billing (FIN) | 11 | 3 | 0 | 2 | 16 |
| Security (SEC) | 11 | 4 | 2 | 2 | 19 |
| Move from PMPro (MIG) | 14 | 3 | 1 | 0 | 18 |
| Servers (OPS) | 1 | 2 | 0 | 0 | 3 |
| Start-up blockers (B) | 2 | 0 | 0 | 0 | 2 |
| All | 39 | 12 | 3 | 4 | 58 |
Verdict. Not ready to switch off PMPro yet. Three risks stand in the way. Two wait for a colleague: an answer on MIG-13, and the Business owner accepting MIG-17. One is Thomas's. MIG-16: the fix is built, and he measures the Mailchimp work and sets the server up a week before the day. On 27 October two more were fixed, the day the Business owner decided them: FIN-3 (decision 21, B) goes live with the next FMS update, and MIG-12 (decision 20, C) with the new website plugin, which Thomas still checks on the test copy of the website. Six smaller technical items remain, listed under Technical. Two old acceptances and one new one (SEC-17, Claude reading FMS) need the Business owner's signature (see the sign-off sheet).
Two risks were added on 15 October, when the plan was to move members to FMS a group at a time (decision card 52). MIG-17: while PMPro is still switched on, it still acts on members who have moved. Since 27 October everyone moves on one morning, so that lasts only the few days before PMPro is off. MIG-18: unused PMPro gift codes and discount codes are not moved by anything. On 27 October the Business owner confirmed there are none, so MIG-18 is closed.
Four risks were added on 13 October, from the test of Omise (Opn Payments) as a second card company: FIN-14, FIN-15, SEC-19 and OPS-3. None blocks cutover, because no real Omise account is connected. On 14 October Omise answered our questions. Renewals are not held for a bank check (FIN-15 is partly fixed), but that adds FIN-16: if a member disputes a renewal with their bank, we lose the money.
Before cutover
These must be fixed, or signed off by the Business owner, before PMPro is switched off.
| Code | What could go wrong | Who | What happens next |
|---|---|---|---|
| FIN-3 | A member whose renewal is being retried loses articles while still paying | Business owner · Thomas | Fixed 27 Oct (decision 21: B, up to 30 days). Goes live with the FMS update before the morning |
| MIG-12 | If FMS goes down, every paying member is locked out of every article | Business owner | Fixed 27 Oct (decision 20: C, 24 hours). Thomas checks it on the test copy of the website; the new plugin is installed before the morning |
| MIG-13 | Members get new pages and emails with no warning, and think it is a scam | Marketing | Answer decision 19 |
| MIG-16 | On cutover day, checks and the Mailchimp clean-up stall at full size | Technical | Thomas measures the speeds and sets the server up a week ahead |
| MIG-17 | In the days between the move and PMPro off, PMPro still changes members FMS already serves | Business owner · also Technical | Accept it, and choose how many days, on decision 52 |
Business owner
FIN-3. A renewal fails, and a paying member loses access · High · Fixed 27 Oct
What could go wrong. When a renewal fails, Stripe tries the card again for a few weeks, and most of these members pay in the end. Until 27 October FMS stopped their articles at once, while some newsletters still treated them as members.
For example. A member's card expires on the day they renew. They update it ten days later and the next try works. For those ten days they paid for nothing they could read.
How likely, how bad. Likely: cards expire every month. Each case is one member, cut off for days.
What we did. On 27 October you chose B on decision 21, and Thomas built it the same day. A member whose Stripe renewal fails now keeps reading, and keeps their newsletters, for up to 30 days while Stripe retries. A payment that works puts them back to normal; when Stripe gives up and cancels, access ends. The website and the newsletters now agree about these members. A member who is behind cannot pay for a second membership by mistake. It goes live with the FMS update before the morning, and Thomas checks that each Stripe account retries for 30 days and then cancels.
What we need from you. Nothing. Finance may still comment on the 30 days.
MIG-12. If FMS goes down, members are locked out · Medium · Fixed 27 Oct
What could go wrong. After cutover the website asks FMS who may read each article. Until 27 October, if FMS did not answer, every paying member saw the subscribe message on every members-only article.
For example. FMS restarts for ten minutes at 2 am. Everyone reading then was locked out.
How likely, how bad. Possible: any update or fault. Short, but it hits every member at once.
What we did. On 27 October you chose C, 24 hours on decision 20, and the website plugin (version 0.57.0) does it, built the same day. When FMS does not answer, each member keeps their last answer for up to 24 hours; visitors still see the subscribe message. A website still set to the old "fall back to PMPro" choice works the same way once PMPro is off. The other half of this risk, the plan to go back to PMPro if cutover fails, was already fixed: in the days after everyone moves, while PMPro is still on, one click hands the website back to PMPro, and one group, or everyone, can go back on the Migration screen (card 52). Thomas checks the outage behaviour on the test copy of the website before the morning.
What we need from you. Nothing.
MIG-17. PMPro still changes members who have moved · Medium · Before cutover
What could go wrong. Everyone moves to FMS on one morning (card 52). PMPro stays switched on for a few days after that, so we can go back in one click. In those days PMPro does not know that FMS now serves everyone. Its nightly check still ends a free membership when PMPro's end date passes, and its Mailchimp link then takes the member's newsletter labels away. PMPro may also send its own "membership expired" email.
For example. A journalist with a free year moves with everyone on Tuesday 11 November (proposed; the owner sets the date, #18). PMPro's copy ends on 13 November. That night PMPro drops their level and Mailchimp stops their newsletters. On the website they keep reading, because FMS decides for them now.
How likely, how bad. Possible: only members whose PMPro end date falls in those few days. No money is involved, and FMS puts the labels back.
What we are doing. Built 15 Oct: the website asks FMS, not PMPro, whether a moved member may read. It lists every change PMPro makes to a moved member, so we see each case. FMS puts the newsletter labels back when it next updates that member, and once more after PMPro is off. Since 27 Oct the window is days, not weeks. Staff change members in the FMS console only, never in PMPro.
What we need from you. Accept this as the price of keeping PMPro on for a few days, and choose how many, on decision 52.
MIG-18. Unused PMPro gift codes and discount codes · Medium · Closed 27 Oct
What it was. Gift memberships bought through PMPro, and PMPro discount codes, are not moved to FMS by anything. Had any been left unused, a gift link would have asked the person to pay once PMPro was off, and a company's discount code would have stopped working with no warning.
Your answer. On 27 October the Business owner confirmed there are no unused PMPro gift codes and no PMPro discount codes with uses left. Nothing needs settling when PMPro is switched off.
If one turns up. Staff give that person the membership by hand, as a free membership with an end date on the member's page.
MIG-5. Articles locked by category could become free · Fixed 15 Oct
What it was. PMPro can lock a whole category of articles at once. FMS locks articles one by one. An article locked only through its category would have become free at cutover.
For example. If the category "Investigations" were locked as a whole, every investigation would have opened to the public on cutover day, and nothing would have warned us.
What we did. Fixed 15 Oct — the sync now locks every article a locked category covered. Each one gets its own lock, at the cheapest tier PMPro let read it. The website's check before PMPro is switched off now refuses while any such article has no lock. Thomas still runs it on the live site. Articles added to that category after cutover need their own lock, like any new article.
What we need from you. Confirm decision 4.
MIG-3. Two old PMPro features · Fixed 24 Oct
What could go wrong. A colleague with PMPro's membership manager role, or a member with a delayed start, loses that when PMPro is off.
For example. A colleague who edits memberships in the website without being an administrator can no longer do it.
What we did. Both now exist in FMS. The colleague gets a Membership manager sign-in on the console. A plan can start with free days: First payment after (days) on the Plans screen; the member reads at once and pays on day N. Thomas still checks the live site, and the website's readiness page lists any old level that waits before its first payment.
What we need from you. Confirm decision 33.
FIN-6. Free access while a payment was checked by hand · Fixed 2 Oct
What it was. In a rare case, FMS kept a member's access open while staff checked which of the two Stripe accounts billed them. There was no deadline, so access could stay open with nobody paying.
For example. A member billed by the Singapore account, while FMS was waiting for someone to confirm it.
What we did. FMS now finds the payment on the other Stripe account itself and links it. If neither account is paying for that plan, the member gets the normal grace period, like any failed renewal.
What we need from you. Nothing.
SEC-17. Claude reading FMS · High · Accepted, please confirm
What could go wrong. Colleagues can now ask Claude questions about members, teams and revenue. Claude reads as the colleague, read-only. Two things remain. Someone could trick a colleague into approving their Claude, by sending them a sign-in link. And what Claude reads is sent to Anthropic, which holds it under Frontier's Claude plan.
For example. A stranger emails a colleague "please sign in here to fix your account". The link is really the stranger's Claude asking for access. If the colleague signs in, the stranger's Claude can look up members until someone cuts it off.
How likely, how bad. Unlikely: the colleague must ignore a warning on the sign-in page. Bad when it happens: member names, emails and payment amounts are read. Nothing can be changed or paid.
What we are doing. It is built and switched off. Claude reads through its own database login that can only read: the database itself refuses any change, and FMS will not start the connector in production without it. Four code reviews tightened the sign-in and the lookups; the fourth (4 October) found nothing serious. Changing your password, by any route, ends your Claude connection, and so does restoring a backup. Every sign-in and question is on Audit under the colleague's name. Connections are listed on Your account and Staff, and an owner can end them in one press. Every time Claude signs in, the colleague gets an email (and the admin alert address a copy), so a sign-in they didn't expect is noticed. It needs the mail relay set up. A person who asks a great many questions in an hour also alerts the admin address.
What we need from you. Confirm decision 43. Legal confirms the data side on the same card. That is your signature for this risk.
FIN-15. Renewals through Omise needing the member every time · Partly fixed 14 Oct
What it was. Omise might have asked for a bank check (3-D Secure) on every card payment, so each renewal would wait for the member to confirm it with their bank. Most would not, and they would lose access.
What Omise told us (14 October). Our test account uses a dynamic bank check. A payment asks for the check only when FMS sends a return address with it. FMS sends one with the first payment, while the member is at the card form, and never with a renewal. So renewals go through without the member.
What we did. FMS sends renewals without a return address, and a test in the Testing screen (Opn renewal skips 3-D Secure) checks that on Omise's test account. If Omise ever asks for a bank check on a renewal anyway, the member still gets the Confirm payment button and 14 more days of reading, and staff now get an email saying Omise changed something.
What is left. The live account works this way only once Omise's risk team approves it. Thomas asks before any live Omise key.
What we need from you. Nothing for this one. See FIN-16.
FIN-16. A disputed Omise renewal is our loss · Medium · Before Omise is first for memberships
What could go wrong. A payment made without the bank check is the shop's responsibility if the cardholder disputes it. Every Omise renewal is such a payment, because that is what lets it go through without the member. If a member tells their bank they did not agree to a renewal, the bank takes the money back, and Omise keeps its fee.
For example. A member forgets they have a yearly membership. The renewal goes through in March. They see it on their statement and dispute it. We lose the payment and the fee.
How likely, how bad. Rare, because the first payment had the bank check and members are emailed before their membership ends. Each case costs one payment.
What we are doing. Disputes reach staff by email. The first payment is checked by the bank, and every renewal names it, which is how card networks expect renewals to look. Since 15 Oct the member is shown the exact amount their card type pays (in baht where it is baht) before they press Pay, FMS charges only that amount, and the amount shown is kept with the payment as our evidence.
What we need from you. Decide whether you accept this before Omise takes memberships first (decision 48). Thomas asks Omise's risk team to approve the dynamic bank check on the live account.
Sign-off sheet
Risks we live with instead of fixing. The rule is that the Business owner signs each one. Two were accepted before that rule existed, and need your signature now. The third is new.
MIG-1. Free members lose 172 articles PMPro let them read. Accepted by Thomas on 26 August, so the migration could go ahead unchanged. Confirming decision 1 is your signature.
SEC-3. Copies of the Stripe keys on the developer's computer. Needed to read live member records for the migration. They can only read, never move money. Accepted by Thomas on 10 August. Please sign, or ask Thomas to delete them sooner.
SEC-17. Claude reading FMS. Accepted by Thomas on 3 October, with the safeguards above and switched off until you confirm. Confirming decision 43 is your signature.
MIG-8 and FIN-2 were proposed for this sheet. Thomas fixed both instead, so they need no signature.
Marketing
MIG-13. Telling members about the cutover · Medium · Before cutover
What could go wrong. Members see a new account page, a new checkout page and new emails without warning. Some think it is a mistake or a scam, and write to support in the busiest week.
For example. A long-time member gets a Welcome email from an address they do not know, and forwards it to support asking if it is phishing.
What we are doing. The technical parts of this risk are fixed.
What we need from you. Answer decision 19.
MIG-4. Lapsed members kept paid newsletters · Fixed 2 Oct
What it was. On cutover day, Mailchimp still carries PMPro's labels. People who stopped paying would keep getting members-only newsletters until someone cleaned them up.
For example. A member whose membership ended in 2022 still gets Political Insider.
What we did. The clean-up is now a cutover step, behind a switch that is off the rest of the time. A regular check also finds people in Mailchimp with paid labels who are not members. Since 3 October the clean-up keeps the free newsletters (decision 41).
What we need from you. Confirm decision 41. Expect one wave of changes in Mailchimp on cutover day.
SEC-7. Fake sign-ups on the checkout page · Fixed 2 Oct
What it was. Anyone could join the free plan on FMS's checkout page without the website's sign-up.
For example. A script could type 500 strangers' email addresses there, and each would start receiving our newsletters.
What we did. Joining for free now needs a website account first, as it does on the website.
What we need from you. Confirm decision 10.
Finance
FIN-10. Refunds or disputes FMS missed · Fixed 2 Oct
What it was. FMS did not re-check refunds, disputes or invoice totals against Stripe, so a missed one would have gone unnoticed in Reports.
For example. A $150 refund made by hand in Stripe never reaches FMS. Reports shows $150 too much for that month.
What we did. The Consolidation screen now has a Money ↔ Stripe check. It compares every paid invoice, refund and dispute of the last 90 days with Stripe, and shows the totals side by side. Finance can fix refunds and disputes from there.
What we need from you. Nothing. Run it before each month-end, and tell Thomas if a Reports figure ever disagrees with Stripe.
OPS-3. Money through two card companies · Medium · Before any live Opn key
What could go wrong. With Omise connected, payments arrive through two companies. Omise pays us in Thai baht. Its fees and refunds look different from Stripe's. A month-end check could miss an Omise payment or count it wrongly.
For example. A member pays $50 through Omise. The bank receives baht, less Omise's fee. Finance looks for $50 in the Stripe totals and does not find it.
What we did. Reports show baht in their own section, never added to dollars. Each payment says Card · Opn or Card · Stripe. FMS checks Omise for missed messages every 15 minutes. Omise told us on 14 October that it never sends a message twice, so this check is the only safety net and stays on. The Health screen shows each Omise account. Refund fees follow Omise's rule: the fee comes back only when a payment is refunded in full before Omise pays it out to us.
What is left. The Consolidation screen compares FMS with Stripe only, not with Omise yet.
What we need from you. Tell Thomas whether the baht section of Reports is enough for month-end (decision 48).
FIN-3
The Business owner decided it on 27 October (decision 21, B): up to 30 days of reading while Stripe retries. Built the same day. Finance may still comment on the 30 days.
Legal / compliance
SEC-10. Deleting a member's data on request · Medium · By November
What could go wrong. We cannot answer a legal "delete my data" request on time. The console's download of the whole database is not encrypted. Nobody is named for the card companies' yearly security form (PCI).
For example. A former member asks us to delete everything. Their data is in six places, and nobody has a list.
What we need from you. Answer decision 22.
FIN-12. Newsletters to a shared inbox · Medium · By November
What could go wrong. A member can send their newsletters to an office inbox. The people reading it cannot stop them. Anti-spam rules expect that they can.
For example. A colleague who reads the shared inbox clicks Unsubscribe, and nothing changes.
What we are doing. The other parts of this risk are fixed.
What we need from you. Answer decision 23.
SEC-9. Member data in files on the developer's computer · High · Please confirm a deadline
What could go wrong. The migration needs full copies of the live website and of the Stripe member lists. They sit on the developer's computer. If that computer were lost or broken into, member names, emails and payment histories would leak.
What we did. Fixed on 2 October: the website no longer keeps its key to FMS in its database.
What we propose. Thomas deletes the data copies within 30 days after cutover, and tells Legal when it is done.
What we need from you. Confirm the 30 days, or give a shorter limit if Frontier has one.
Technical (Thomas)
Listed so everyone can see the split. No action needed from colleagues.
| Code | What could go wrong | When |
|---|---|---|
| FIN-11 | Three rare glitches: a team that stopped paying keeps access, or a paying member is cut off by mistake | After cutover |
| OPS-1 | The nightly copy of the database to off-site storage has never run against the real storage | Deploy day. A missing copy now shows on the Health screen |
| SEC-9 | Member data copies on the developer's computer | Within 30 days after cutover, if Legal confirms |
| SEC-14, 16 | Extra protection for the payment pages, and small gaps in the website plugin | November |
| FIN-14 | An Omise payment goes through, but FMS never hears the answer | Before any live Opn key |
| SEC-19 | The Omise keys and message password | Before any live Opn key |
FIN-14. An Omise payment goes through, but FMS never hears the answer · Medium · Before any live Opn key
What could go wrong. If the line drops after FMS asks for a payment, the card may be charged while FMS does not know. Asking again could charge twice.
For example. FMS charges a renewal at 2 a.m. The connection times out. Omise did take the money.
What we did. FMS writes down every payment before it asks, and never asks twice. Since 14 October each payment also carries FMS's own reference, which Omise uses to refuse a second charge for the same payment. Every 15 minutes it reads Omise's list of events. After an hour it looks the payment up at Omise. If it finds it, the membership is renewed. If money arrives for a membership that already ended, staff get an email to refund it or give access.
What is left. All of this was tested against a stand-in for Omise, not the real one. Thomas tests it with Omise's test account.
What we need from you. Nothing.
SEC-19. The Omise keys and message password · Medium · Before any live Opn key
What could go wrong. Omise's secret key can charge any saved card on our Omise account, and refund. Omise has no weaker, read-only key. A second password checks that messages really come from Omise. If someone stole it, they could send fake messages.
What we did. Both are stored encrypted. A stolen database alone is not enough. FMS refuses test keys on the real system and real keys on test copies. Real Omise charges are blocked until Thomas deliberately switches them on. A fake message only makes FMS ask Omise directly, so it cannot change a payment.
What is left. Omise has not said which addresses its messages come from, so the firewall cannot check them. Changing the keys has not been practised yet. Steps are in the runbook.
Since 14 October. Members who pay through Omise change their card on FMS's own billing page (card 49). It uses the same card form as checkout, so Omise receives the card number, never FMS. It has the same limit on repeated tries.
What we need from you. Nothing.
MIG-16. Cutover day at full size · High · Before cutover
What could go wrong. On cutover day FMS checks about 21,000 members against Mailchimp and Stripe, then corrects Mailchimp. Those checks used to stop after about a minute and a half, because the web connection gives up. The clean-up sent one request per member from the browser.
For example. Thomas presses the check button. After 100 seconds it fails with nothing to show, and the clean-up cannot start.
What we did. The slow checks now run in the background, with progress and a Cancel button. A member Mailchimp will not return no longer spoils the whole check: the result says it is incomplete. The clean-up is one press. New members still reach Mailchimp first. The member import warns about memberships that have already ended.
What is left. Thomas measures how fast Mailchimp answers, on a test server, and sizes the day. On the day the server gets more database connections. (It no longer matters which copy the console is switched to: since 24 October the live system keeps working whatever a tester looks at — card 55.)
What we need from you. Do not change a plan's newsletters while the clean-up runs. Expect it to take hours, not minutes.
Already fixed or accepted
| Code | What it was | State |
|---|---|---|
| B0 | The system would not start | Fixed 10 Aug |
| B1 | Two cutover instructions disagreed | Fixed 10 Aug |
| FIN-1 | Price changes on the console never reached Stripe | Fixed 25 Aug by refusing the edit. Since 16 Oct the edit goes through and Stripe follows: a new price for new members, existing members keep theirs |
| FIN-2 | A failed cancel could leave a member billed twice | Fixed 2 Oct. Consolidation flags anyone billed twice |
| FIN-4 | After the first stuck background job, staff got no further warnings | Fixed 2 Oct. Since 6 Oct, replaying an old failed-payment message for a renewal the member has since paid does nothing |
| FIN-5 | Retrying with another card locked a member out of checkout for a day | Fixed 26 Aug |
| FIN-6 | Free access with no deadline while a payment was checked by hand | Fixed 2 Oct |
| FIN-7 | The charging and cancelling code had no automatic test against Stripe | Fixed 2 Oct |
| FIN-8 | A failed renewal FMS had not linked yet got no grace period | Fixed 2 Oct |
| FIN-9 | Messages from Stripe that FMS ignored were lost for good. Now kept 90 days and can be re-read | Fixed 2 Oct |
| FIN-10 | Refunds and disputes were not re-checked against Stripe | Fixed 2 Oct |
| FIN-13 | Renewals waiting for a bank confirmation looked like plain failures | Fixed 15 Aug |
| SEC-1 | Test settings on the live server would let outsiders sign in as anyone | Fixed 2 Oct |
| SEC-3 | Read-only Stripe keys on the developer's computer. They cannot move money | Accepted 10 Aug. Business owner to sign |
| SEC-4 | Forged payment messages through an unknown account address | Fixed 2 Oct |
| SEC-5 | A payment message could change another Stripe account's records | Fixed 26 Aug |
| SEC-6 | A test copy of the system could write to the real Mailchimp list | Fixed 26 Aug |
| SEC-7 | Fake sign-ups on the checkout page | Fixed 2 Oct |
| SEC-11 | The archive's lock could be bypassed, letting anyone read it | Fixed 22 Sep |
| SEC-12 | The archive's sign-in link carried a powerful pass in the address bar | Fixed 22 Sep |
| SEC-13 | The live console could open with a password anyone can look up | Fixed 2 Oct |
| SEC-15 | Card-testing on the donate and gift pages; passwords sent unencrypted | Fixed 2 Oct |
| SEC-20 | A test copy of the system could take the live system's payment messages | Fixed 24 Oct (decision 55) |
| SEC-2 | The staff sign-in is protected by the same secret as members' sign-ins | Partly fixed 24 Oct: fixed one day after the new staff secret (ADMIN_SESSION_SECRET, with the date it was set in ADMIN_SESSION_SECRET_SINCE) is set on the server. Nobody is signed out |
| SEC-8 | A staff member's other sign-ins stayed open after a password change, and nothing checked that a click came from our own page | Fixed 24 Oct |
| SEC-17 | Claude reading FMS: a colleague could approve someone else's Claude, and what it reads leaves FMS (decision 43) | Accepted 3 Oct. Switched off. Business owner to sign |
| SEC-18 | Every console user, even read-only, could be sent the database password by the environments list | Fixed 3 Oct |
| SEC-21 | A Developer who restores an old backup could get back a role they once had, because a restore brings back staff roles as they were then (decision 37) | Accepted 7 Nov: every restore is on Audit for all to see, and only owners change roles. Fix to follow: FMS will remember role changes through a restore |
| MIG-1 | Free members lose 172 articles (decision 1) | Accepted 26 Aug. Business owner to sign |
| MIG-2 | No member emails after PMPro (decision 2) | Fixed 29 Sep |
| MIG-4 | Lapsed members kept paid newsletters after cutover | Fixed 2 Oct |
| MIG-5 | Articles locked by a whole category would become free (decision 4) | Fixed 15 Oct — the sync now locks every article a locked category covered; Thomas still runs it on the live site |
| MIG-6 | The setup file was wrong, and a missing key failed silently | Fixed 10 Aug |
| MIG-7 | A member with two website logins was locked out, and staff could not fix it | Fixed 2 Oct. The member's page can move the login (decision 40) |
| MIG-8 | No alarm for a broken Stripe or Mailchimp connection | Fixed 2 Oct. The Health screen shows each connection |
| MIG-9 | Imported members might point at the wrong Stripe account | Fixed |
| MIG-10 | The scheduled Consolidation report was off and undocumented | Fixed 25 Aug |
| MIG-11 | No growth or churn figures | Fixed 2 Sep |
| MIG-14 | Out-of-date documents | Fixed 14 Aug |
| MIG-15 | The import and Mailchimp updates broke at full size | Fixed 23 Sep |
| MIG-18 | Unused PMPro gift codes and discount codes would not be moved | Closed 27 Oct: the Business owner confirmed none exist. One that turns up is given by hand |
| OPS-2 | Test tools could move real money | Fixed 12 Aug |