We generally only package released versions of apps, as otherwise it becomes impossible to test all combinations. Hopefully they make a new release soon, which would then likely include the fix.

@Crush33 Can you give us access to your instance (possibly a cloned instance of your existing dolibarr?) . If so, can you write to me on support@cloudron.io and I can try to take a look. There is possible some bug in the package causing this.

Hi, I had same problem today. I was unable to connect to admin account using password. A workaround I did was to edit Dolibarr "admin" account username to an already existing Cloudron username (using a Dolibarr account that had administrator rights). I could then connect with OIDC on the edited admin account. But I'm pretty sure I was able to connect to that admin account with username/password months ago. I'm not a big fan of the workaround I used today.

thanks a lot for the update, it works and was able to put this option on my apps.

Hello @Crush33 @Crush33 said in how to implement fix on core files ?: does the database of dolibarr will be lost after quitting the recovery mode ? No. The database stays as it is. If you make changes while in recovery mode, those changes will persist. @Crush33 said in how to implement fix on core files ?: does the files in /app/data/dolibarr will be lost too ? No. Only changes made to the normally read-only sections will be lost.

Hello @Crush33 With apps that allow plugins or extensions, it is almost impossible to test and verify everything that is out there. It is the developer's responsibility to provide extensions that work. For the future, please don't use screenshots for code. I can't copy-paste some of the PHP code for testing since it is a picture. I was able to get the code via OCR and put it into /app/data/custom/this.php <?php //phpinfo(); //var_dump($_SERVER["CONTEXT_DOCUMENT_ROOT"]); // Load Dolibarr environment $res = 0; // Try main.inc.php into web root known defined into CONTEXT_DOCUMENT_ROOT (not always defined) if (!$res && !empty($_SERVER["CONTEXT_DOCUMENT_ROOT"])) { $res = @include $_SERVER["CONTEXT_DOCUMENT_ROOT"]."/main.inc.php"; } // Try main.inc.php into web root detected using web root calculated from SCRIPT_FILENAME $tmp = empty($_SERVER['SCRIPT_FILENAME']) ? : $_SERVER['SCRIPT_FILENAME']; $tmp2 = realpath(__FILE__); $i = strlen($tmp) - 1; $j= strlen($tmp2) - 1; while ($i > 0 && $j > 0 && isset($tmp[$i]) && isset($tmp2[$j]) && $tmp[$i] == $tmp2[$j]) { $i --; $j --; } if (!$res && $i > 0 && file_exists(substr($tmp, 0, ($i+1)) ."/main.inc.php")) { $res = @include substr($tmp, 0, ($i +1)) ."/main.inc.php"; } if (!$res && $i > 0 && file_exists(dirname(substr($tmp, 0, ($i+1))) ."/main.inc.php")) { $res = @include dirname(substr($tmp, 0, ($i+1)))."/main.inc.php"; } // Try main.inc.php using relative path if (!$res && file_exists(" .. /main.inc.php")) { $res = @include " .. /main.inc.php"; } if (!$res && file_exists(" .. / .. /main.inc.php")) { $res = @include " .. / .. /main.inc.php"; } if (!$res && file_exists(" .. / .. / .. /main.inc.php")) { $res = @include " .. / .. / .. /main.inc.php"; } if (!$res) { die("Include of main fails"); } When I access this file with the browser path $DOMAIN/custom/this.php I get: [image: 1750748868980-cf420bdc-1153-417c-a6a4-0099ac6086f4-image-resized.png] Simply testing: <?php //phpinfo(); var_dump($_SERVER["CONTEXT_DOCUMENT_ROOT"]); This shows: string(16) "/app/code/htdocs" And with this as path to main.inc.php is working.

Fixed, thanks for reporting

Do you have any update on this @ruihildt ? We have pending MR which may or may not fix the issue, but we require your input here.

Hi, this seems to be more of a question how to use Dolibarr, not so much about the Cloudron package for Dolibarr. Maybe someone here can help out, but I think it is better to ask the upstream project itself https://www.dolibarr.org/

This should be fixed in the latest package.

That seems to be question very specific on how to use the app itself. Maybe the dolibarr community forums are the better place to ask this: https://www.dolibarr.org/forum.php

@ccfu How do you disable the LDAP module?

Ok, I used LAMP stack and it works. Once I had my LAMP stack set up, I proceeded with the migration process. Here's a detailed breakdown of the steps I followed to ensure a smooth transition: Database Backup: The first step involved creating a backup of the SQL database from the old server. This is crucial to ensure that all data is securely transferred without any loss. Copying Data: Next, I archived the dolibarrdata directory into a .tar.gz file. I did the same for the /modules directory located in the core. This step is essential to retain all the configurations and customizations. Preparing the LAMP Container: In the root directory of the LAMP container (specifically in /data), I created an /import directory. This was done to facilitate the import of the previously backed-up data. Importing the Database: Before installing Dolibarr, I imported the database into the LAMP stack. It's important to do this step prior to the installation to ensure the new setup recognizes all your existing data. Cloning Dolibarr: I used Git to clone the 18.0 branch of Dolibarr. While doing this, I made sure to use the option for a single branch and a depth of 1 to avoid downloading unnecessary data. Dolibarr Installation: With the database in place and the Dolibarr code ready, I proceeded with the installation. It's critical to use the LAMP credentials provided during this step. Note that the database is in MySQL and not in localhost. Also, ensure that Dolibarr points to the imported dolibarrdata. Final Adjustments: The last step involved adjusting the path since Dolibarr was now at the root instead of in the htdocs directory. This is an important modification to ensure that Dolibarr functions correctly in its new environment. By following these steps, I successfully migrated Dolibarr to a more flexible setup using a LAMP stack. This approach might seem a bit complex, but it offers greater control and customization options, which were lacking in the standard Cloudron setup. Hope this detailed walkthrough helps anyone facing similar challenges. Feel free to ask if you have any questions or need further clarifications.

@girish By following your procedure it works! I didn't know it was possible to change the memory allocation to the mysql database in the services. Sorry I didn't think of it. By doing so, the installation was much faster and worked first time. At least now I understand Cloudron's added value even better Thanks for your time

Hello @luckow. I have an issue with two modules I want to use with dolibarr. The problem is that I can add the modules to the "custom" folder in Cloudron, but I cannot make any modifications. I can not install them either by the tab "add external modules" since Dolibarr shows an error that it can't write in the folder "/app/code/htdocs/custom", which is normal, since the folder does not exist. By looking through the forum I found your post. Since I'm not a programmer I do not know what your solution means and if can I do a modification that would let me use the modules correctly or does that have to be done by the developers of the modules. If you could help me out here that would be great. Best regards, Bob

@JOduMonT thanks that you bring this up again. The multiDomain can easily be added, I am just wondering how I can test that it works. I don't have much clue about how to use dolibarr to be honest.

This should be resolved with the latest version.

@girish Basically these are php files that make use of db variables and properties defined in the GUI. However, to make (in my opinion essential) customizations, I need to edit these templates. These changes however are mostly to optimize the user experience. For me they dont need to be editable during runtime. If i could make the changes persist in recovery mode and the restart the app with the adapted files in readonly, that would be perfect. Best

@JOduMonT thanks for the info and research. The encrypted password handling in dolibarr as described does not make too much sense for us, since the password might change during package update, depending on the database addon thus it always have to be fetched freshly. Further it will always be present in the app's environment as injected into the container. For phpinfo() I am not sure how this is an attack angle, since if one is able to inject php code to run phpinfo() the attacker might as well just simply dump the env variables manually.