Edit History

After incorrectly adjusting the data, I deleted all the tables and restored them from a backup.
At first, everything worked, but then strange glitches started to happen. And at some point, I stopped logging into the admin panel for no reason.
Dancing with tambourines and the proposed solutions did not lead to anything.

I found a quick intermediate solution - to replace the admin role in the ps_employe table with a logistician - after that I was able to log into the admin panel with limited functionality.
And before that, be sure to clear the cookies in the browser, not the cache, but the cookies

You can grant more permissions with a query, where 2 is the logistician profile:
INSERT INTO ps_access SELECT 2, `ar`.`id_authorization_role` FROM `ps_authorization_role` ar
LEFT JOIN ps_access a ON( ar.id_authorization_role = a.id_authorization_role AND a.id_profile = 2)
WHERE a.id_profile IS NULL

What happened in the end?
When I created a backup copy of the database from phpmyadmin, the information about the indexes was not saved. And I deleted all the tables and restored everything, but without indexes ((

After that, when the site was running, new records did not become unique (autoincrement, primary indexes fields) and when adding new records, everything stopped working correctly. As a rule, new index fields became 0, not autoincrement.

I had to manually create indexes for all tables, based on the installation files of Prestashop and modules.
If there are modules with non-critical information, it is easier to reinstall the modules after restoring access.

Due to the fact that some records in the tables ceased to have a unique field, to add an index it was necessary to either delete fields with the same values with a similar query:
delete from ps_lang where id_lang = 0;
Or do autoincrement field or use other script to make a field unique. Without uniqe values you can not create index and phpmyadmin will throw error.

After I corrected the indexes in ps_tab I was able to log in to the admin panel normally.
In total, 3 days were spent searching for the cause and eliminating the consequences on the working site.

Conclusion - when creating a backup copy of the database, check for the presence of information about the indexes. It is even better not to delete the tables completely, but to empty them and import new data - this way the indexes will definitely not be deleted. And it is best to carry out the operation on specific tables where there may be problems, and not all of them.

Example where there is information about index (PRIMARY)
CREATE TABLE IF NOT EXISTS `ps_access` (
`id_profile` int(10) UNSIGNED NOT NULL,
`id_authorization_role` int(10) UNSIGNED NOT NULL,
PRIMARY KEY (`id_profile`,`id_authorization_role`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

To simplify the work, use Notepad++ or an editor for large files.