Today I had a big WTF moment.
Hi,
first of all, the problem is (maybe) solved.
What was the problem, better the root of the problems.
It was a combination of my v7 > v8 migration problem ([Solved] Migration 7.x to 8.x allways fails with "Unauthorized access to administration")
SuiteCRM Finalize Upgrade
============
Running: legacy-post-upgrade
step: legacy-post-upgrade | status: failed
Unexpected error running Legacy Post Upgrade
Unauthorized access to administration
and the “blank page” Problem.
When I set up a v8 environment to migrate from v7, no NEW DB was generated because the migration rebuilds the v7 DB.
So in the process the
SuiteCRM Finalize Upgrade
============
Running: legacy-post-upgrade
step: legacy-post-upgrade | status: failed
Unexpected error running Legacy Post Upgrade
Unauthorized access to administration
Problem.
I had solved this by disabling the if (!is_admin($current_user)) check in the source code, as suggested.
The migration then went through but after that I had the blank page problem (api/graphql not found) problem.
I had solved this by creating a backup of the migrated instance and restoring it to a freshly installed SuiteCRM instance of the same version.
After that SuiteCRM worked again, but I got the login problems that required many attempts.
Today I set up a new server with a blank SuiteCRM v8.3.0 (same version as our running SuiteCRM) and started a file by file and table by table comparison.
To narrow it down I imported the database table by table to the new server and check the login after each import is causing problems.
Fortunately I started with “accounts” followed by “users” tables. All “account” tables work fine, but after importing “users” the login stopped working.
When I check the “suitecrm.users” table and see that the first generated user id=1, I have some gut feeling. So I updated the id of the imported user id=1 to id=2 and restored the original id=1 user from the new server from a snapshot.
And, lo and behold, everything worked fine.
All in all, when you set up a new instance of SuiteCRM, never overwrite the id=1 user.
When restoring a SuiteCRM instance,
- perform a full installation of a new SuiteCRM version,
- save the
id=1user from the DB, - restore the old DB from your backup.
- change the ID of the restored user
id=1to2 - insert the saved
id=1user.
I really wonder what exactly is attached to this 1st user that causes massive problems when it comes from another SuiteCRM installation.
So far so good, thanks to all have tried to help,
Best regards,
Peter