Note: I don’t know if there should be a directory ModuleNameMap by default, I’m just informing you there were no directory ModuleNameMap, I had to create it.
The console reports: VM6094 sugar_grp1_jquery.js:2 [Violation] 'load' handler took 169ms
I was able to replicate the issue on my side. I’ve applied the solution I told you and it worked ok.
Could you check if the case in the letters of your module name is correct?
if you go to public/legacy/custom/Extension/application/Ext/Include there should be a file with the name of your module.
In my case I added a MyModule module, with package prefix of test.
On public/legacy/custom/Extension/application/Ext/Include/MyModule.php I have
<?php
//WARNING: The contents of this file are auto-generated
$beanList['test_MyModule'] = 'test_MyModule';
$beanFiles['test_MyModule'] = 'modules/test_MyModule/test_MyModule.php';
$moduleList[] = 'test_MyModule';
?>
On the fix file public/legacy/custom/Extension/application/Ext/ModuleNameMap/my_module.php in have:
Hi,
I was getting the authorization error yesterday.
I tried your workaround and it worked initially.
When I came back today and tried to access my custom module, i get a text error on a blank screen: Error: Module Staff does not exist.
My file PKG1_Staff.php, as per above, looks like this:
Any thoughts on this issue?
Not being able to create and use a custom module is a significant blocker.
Update:
I was able to get this to work, but not sure why.
Above, you say to look for public/legacy/custom/Extension/application/Ext/Include/MyModule.php
For me, that file was not named MyModule.php but was the full package name.
That is, expected was Staff.php but the file name was PACKAGE1.php.
I created a link: ln -s PACKAGE1.php Staff.php and i was able to see the module.
Not sure how long this workaround will last.
So, some things are not working properly and need to be addressed before the next release.
The reference to public/legacy/custom/Extension/application/Ext/Include/<file>.php, was just to open it and check the machine name for the module. From what I’ve understood in your case the module name is PKG1_Staff.
That module name is the name that should be used on the code inside the public/legacy/custom/Extension/application/Ext/ModuleNameMap/<any_name>.php
As a matter of fact this should not be needed. This is caused as a part of the logic of the acl check that is being too strict, which causes custom module not to be recognized as valid modules if they are not defined on the module_name_map. We are in the process of changing that.
What is module_name_map ?
Module name map, is a map that maps from legacy module names to more “standard” names both on the front end and on the SuiteCRM 8 side backend. Though at the moment it is mostly used for the front end.
When you open the app and go to the accounts module the address is something like <your_instante>/#/accounts/ and not <your_instante>/#/Accounts/ or if you go to Quotes the address is <your_instante>/#/quotes/ and not not <your_instante>/#/AOS_Quotes/. This mapping between the legacy module name and the front end name is declare on the module_name_map.
You can find the core module_name_map at public/legacy/include/portability/module_name_map.php
And we allow to extend the module name map, use the legacy extension mechanism. Which is declared on public/legacy/ModuleInstall/extensions.php.
This extension setup is what allows us to add the file to public/legacy/custom/Extension/application/Ext/ModuleNameMap/<any_name>.php
Database type and version?
PHP version?
Installation method, docker or self-install?
Relevant entries, at the time of the error, in suitecrm.log and php_errors.log?
I am also getting the ‘You are not authorized to view this page…’ error on every user login.
The difference is we have no external modules at all.
SuiteCRM 8.5 (recently upgraded from 8.2.4)
MySQL v 8.0.32
PHP v 8.1.25
Permissions are all ok as far as I can see.
It doesn’t matter if they are an admin user or a regular user, the message still comes up but allows you to click through it and everything operates as normal. Logout is fine.
I have spent most of today tracking the code to try and understand why this is happening but just can’t see anything that is causing it, although I am not an out-and-out coder by any means.
If anyone has any ideas, happy to listen as this is stopping us migrating to 8.5 on the main system as the support desk would not be happy.