'user does not have permission to access account '

[from-nibly]

When I try to create an account via the api and an API key I get an error

'user does not have permission to access account '

First off it looks like there is a template string for the error response, that isn't getting filled out. second why would an API key not be able to access the account APIs when it was able to create the org? I can't seem to find any AuthZ documentation available.

[from-nibly]

OK I figured out that parentID is a required field when creating new Accounts. There is a magical (and apparently NOT INDESTRUCTABLE) "Root" account that you use when you are creating accounts that don't have other parents. This root Account does not show up in the GUI, nor does it show up in any API other than listing all accounts. This means if I want to create a new account that uses the "Root" account as a parent (i.e. a parent-less account) I have to list the accounts, and then search for the one named "Root".

What follows are opinions
I feel that although the root account could just be an account in the database, the API should not expose it similarly. The root account shouldn't be something the API consumer needs to deal with, having a magical "Root" account is just an implementation detail.

Removing this account and assuming accounts created without a parent are just children of the "Root" account will solve a bunch of errors.

1. Won't have to search for the "Root" Account when creating top level accounts.
2. Won't be able to delete the root account accidentally thus causing errors like
   a. Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND date \u003c ? GROUP BY accountId' at line 1
3. "Root" will no longer be a silently sacred account name.
4. The API will be a lot easier to use as you can just omit the parent from the payload and the new account will be created as a root account.

Alternatively if it isn't possible to remove the "Root" account from the list of accounts, it should be made indestructible. Also it should either be noted in the object that it is the root account with a definitive key either something like name being blank (which would presume further that blank would no longer be a valid name). or a new key something like isRoot: true. Or a rootAccount could be exposed on the org object so it would always be possible to find it, no matter if there are name collisions or not.

[pnagurny]

The reason I have a root account is because it makes it simpler to do tree traversal. One of the first things the client does is get a list of all the accounts. It puts these accounts into a tree structure. Then it is constantly traversing that tree... totaling up balances, etc. Having the root account is just like having the / in a linux filesystem. It's the root directory for the whole directory tree.

Finding the root account is just selecting the account with no parent, you don't even need to go by the name. Right now, the client does use hard coded names for Assets, Liability, Equity, Income + Expenses. It checks for depth of 1 so there are no collisions if you have a subaccount called Expenses deeper in the tree. Instead of going by the hard coded name + depth, a type field would probably be more appropriate.

You shouldn't be able to delete an account that has children accounts under it. So the only time you'd be able to delete the Root account is when you first create it.

I do need to look into that SQL syntax error you are getting. I think that might be happening when there are no accounts at all in an organization? That needs to be fixed. If you want to look into it and submit a PR, that would be great!