Can't run 3.1 with Docker

Just found out about Akaunting and have run into this problem straight away while trying to set it up.

I've retried with multiple tag versions back to 2.x (at which point it failed with a Python version error - fine). But every version of 3.x fails to create a new user at line 61 of CreateCompany.php.

Not that it matters, but I'm configuring this in Portainer - I've perfectly able to translate a docker-compose.yml and .env files into the requirements for a stack, and have got the AKAUNTING_SETUP=true set correctly for initial launch (all the database tables appear with my preferred prefix, so I know that bit is working).

I can't manually create a new user because this is a fresh install - I've no way of generating the password hash.

I couldn't find @Viktor Viktor's github issue, but if someone links to it, I'll add comments.

OK,
Digging further, it's falling over when it tries to use "GetAnyActionLimitOfPlan()". From this I reckon it's trying to find out whether I'm allowed to create a new company based on the fact that the self-hosted plan only allows one company. Fine.

So that function calls app/Traits/Plans.php which has a few functions, one of which is called getPlanLimitByType can can be called with "company" as a parameter value. If it fails, the output is the message we're seeing.

Th gPLBT function calls one called getPlanLimits which returns false if it can't get a response from the URL "plans/limits" - I'm beginning to suspect this is where the fault is happening.

I thought that the 3.0.17 is not affected by this but apparently is when you also failed with it. I have not tried that back then.

Here is my issue on github
https://github.com/akaunting/docker/issues/100

But there is next to zero activity from the developers. Most of the people are told to go to the forums, but there is not much activity either.

I will have a look in the evening. I should be able to create either a list of database entries that you have to put in or an sql file that you can import and get around the AKAUNTING_SETUP=true.

Thanks Viktor Viktor.
I'M IN! Got as far as logging in and starting the Wizard anyway.
My solution:
app/Jobs/Common/CreateCompany.php - comment out line 25.
app/Jobs/Auth/CreateUser.php - comment out line 21.

In the database, access the Companies table and change ID to 1 (mine was 8 for some reason).

Yes, I'm aware this is stopping it doing the licence checks and is therefore "naughty", but the developer broke the setup flow of the damn thing, and doesn't seem interested in fixing it.

OK, few more fixes in the database required the Company_ID changing to 1 to match my change in the Companies table. That's fixed a bunch of 500 errors I was getting on things like email templates and the fact that the modules for Offline Payments and Paypal weren't loading.

Thanks Alyn, I came to the same conclusion after looking at the auth code, if we are running locally, the licensing shouldn't matter. Also, on a fresh install, the licensing should definitely allow the first company and user to be created.

Deleting the lines inside CreateCompany.authorize() and CreateUser.authorize() got me through the php artisan phase.

I will try your other suggestions later this evening.

Hi Irhiggs,
According to this page, it does matter:
https://akaunting.com/plans-on-premise
but since it's the developers' fault it's broken, I've decided our fix is appropriate. I think the problem is down to not having an API key at the point of installation, so the API call to check the licence fails. I think it might even be misnamed in the code - the API call I found is called "plans.check" in routes/admin.php but the call being made is to "plans.limits" - I couldn't find that in any of the routes files.

I'm simply done with it.
I would consider paying if the software wasn't so extremely fragile.

I get that they have to prioritize paying customers, but removing the free plan with just 1 week notice means that I haven't been able to explore the product.

All I can see now is an always breaking app. If I have to pay, I'll pay for solid, properly built alternatives that are not tested in production (as it just happened with 3.1).

BTW, tried all your workarounds guys, and I'm still getting the 404 page on the first load.
Good luck

Yes, unfortunately the licensing matters for us as Alyn described. I managed to upgrade my production container, I even deleted all users but one, filled in the API key and I fulfilled the requirements for the free on premise plan. But I am getting the 500s on transactions and customers details. I did not managed to fix that. Access through API was also not really working.

Did you managed to get it running then? How about some errors?
It is kind of a shame that it is do difficult to get it running. The alternatives are doing usually to much. The Akaunting basic package suits my use case quite well.

BTW I am running this digest akaunting/akaunting@sha256:f35f4f77927945a3b7618675d7129be30cd15170e81cfbbc77280651b32affca
It is an older 3.0.17 but works well for me and does not get updated every day.

Hi Viktor,
I have got it working now and following the correction to all the tables to make sure the Company_ID field matched wherever it was found I've not had any more errors related to the installation. I can certainly see the Sales/Customers/Customer Details and Banking/Transactions pages. I've not tried the API.

I wonder if your issue is that the user who entered a Customer's Details or a Transaction is stored in the database tables. If you look at the xxx_transactions table in your database, are all the values for the "created_by" field the id number of your current single user from the xxx_users table? If not, try running an UPDATE query against that table to force all the created_by values to be the one for your only user. Same deal for the xxx_contacts table. I've just been doing it through PHPmyAdmin since I had a container with it installed already sat on the server.

I did then have an issue where values for transactions were never accepted as being filled in by the page validation, but changing to a Chromium-based browser has fixed that.

Like you, I've made sure I'm still within the limitations of the free on-premise plan, although I don't quite understand their reasoning when I'm the one paying for compute, storage and bandwidth. I've now made my own fork of the github repo so I can have some level of control over changes, but I am running the current latest version.