If I delete a business from Cloud Edition, it no longer shows up in the businesses list. If I perform an API query for a list of businesses, it also does not show up. This is good.
However, if I already know what the UUID is for that business, I can…
Get a list of BankPayments for that business
Create a new BankPayment – and I get back a UUID of the new payment record!
Update an existing BankPayment – and I get back confirmation that it’s been updated.
This probably works for all object types!
Clearly the business still exists. Even if there is a technical reason for not cleaning it up immediately … the API should stop allowing requests to it immediately, at the very least.
Otherwise, API requests will return as successful and we’ll think everything is working fine, only to realise later that everything we did has been added to a business we can no longer access.
What did I expect to see?
Deleting a business makes it inaccessible, even from the API.
What did I see instead?
I can make API calls to a deleted / non-existent business, and they return back successful as if nothing has happened. Instead, the API call should fail.
The only one that works as expected is the business list (endpoint /api/index.json).
This stems from a design philosophy to minimize the chances of unintended data loss. Removing a business on the Businesses page only removes its name from the index file, 00000000000000000000000000000000.manager, so the program doesn’t list it. The action does not touch the file itself, so all data remains intact in the applications data folder. Many are the users who removed a business that was still active and needed to recover.
You are obviously quite interested in the API, which appeared on the scene for users only recently and isn’t advertised as being available, has no documentation, etc.
That makes sense, and I definitely agree with the design philosophy. Protect the user from their own mistakes as much as possible.
However, the API should reject requests made to one of these soft-deleted / hidden databases. Only if it is restored, should API requests be allowed.
This is similar to the bug you discovered recently where disabling the checkbox doesn’t remove the starting balance. In the same way, disabling the business doesn’t prevent it from being accessed via the API - but it should. I’m not saying to permanently delete the business, just block access
I ran into this because I made the exact mistake I mentioned:
It’s better for the request to fail, so that we know something isn’t right, and we can investigate further. Even if Manager was to say “hey, this database exists but access has been disabled” … that’d be far better than just letting us go ahead and do whatever we want.
