Yes, that worked perfectly. Thank you!

@joseph thank you. my bad, didn't think about this simple test. The question is irrelevant now.

@nebulon Thank you for your response, I have reset it according to your instructions and it is working.

@zonzonzon apparently, we added these manually when we installed EspoCRM.

@shrey I have added a doc note for the fix - https://docs.cloudron.io/apps/espocrm/#cron-jobs

Apologies for forgetting to reply again in this thread and confirm the problem still existed. Thanks for reporting it upstream. Looks like it could in fact be reproduced and has been fixed.

The group account solution is what I had been using up to now but this had to be reset every time there was an update or the app was restarted.

@marcusquinn Yes.. I tried to copy and paste that url, but it seems part of a redirection process, so pasted urls seems to be not good (or expired)...

@p44 this was a bug in how cloudron parses names. I have added a workaround in https://git.cloudron.io/cloudron/box/-/commit/8a63f0368e5573014739d4c31ea9c2d53ac00701 for the next Cloudron release.

@nebulon Thank's a lot

Any screenshots/error message will help.

Nope it was not default in order to either feth emails or send mass emails and for some notifications you have to create a cron job

@micmc the issue is related to the espocrm cloud hosting, so we are not affected

@girish You are 100% correct.
Turned off proxied mode and it works fine now.
Real Doh moment.
Thanks for the help!

I checked this again, but it seems that the public directory has a bunch of code.

root@d66257ab-b6ad-4648-acf5-f1dbc2281a80:/app/code/7.2.7/public# find . . ./oauth-callback.php ./robots.txt ./index.php ./web.config ./api ./api/v1 ./api/v1/.htaccess ./api/v1/portal-access ./api/v1/portal-access/.htaccess ./api/v1/portal-access/index.php ./api/v1/index.php ./portal ./portal/.htaccess ./portal/index.php ./install ./install/img ./install/img/devices.png ./install/js ./install/js/install.js ./install/css ./install/css/install.css ./install/index.php

Do you remember what extension writes where? Is it in a subdirectory under public or does it write straight under public itself?

@robi Looks 💩

We already have EspoCRM Email way more advanced than that.

@dogansur this forum is very helpful.. .

@timbo if you install the latest package v2.1.0, you will see an option to leave user management to the app (when installing the app). You have to install a new app, Cloudron currently has no way to switch the LDAP integration flag after installation.

Some notes on aclStrictMode. It was removed in this upstream issue.

Checking
Check /app/data/data/config.php in the File manager and search for aclStrictMode. If it's set to false, it means it's disabled and you must migrate to using proper access control/roles in Espo.

Roughly, you can do this as follows:

Administration -> Roles. Create a role called say users and give it all permissions. Ours is configure like this:
2385a68b-1314-4940-af85-e51e844ffdfc-image.png

Administration -> Teams. Create a team called everyone and then give the users role. You can also add users into the team in the Teams page.
e96825bf-c56a-4852-bf76-2381e29302d3-image.png

You can also auto-assign teams to a new LDAP user. Administration -> Authentication.

a97abfcb-c1d5-428d-a60e-56b272a9355d-image.png

Remove the aclStrictMode field in /app/data/config/config.php

Restart the app and check if it all works.

@nebulon Never say never! We wouldn't be jumping through all these obstacles if it weren't that we are forced to for lack of practical alternatives. These are very valuable solutions for everyone to have both reliable and debuggable apps, and LDAP across multiple servers where one server stack cannot fulfil needs.