Setup Other: Difference between revisions

m
Tag: 2017 source edit
Tag: 2017 source edit
Line 700: Line 700:
The following options are useless for a common usage of Dolibarr. But they are usefull if you plan to host / provide Dolibarr instances as Software As A Service (SAAS) to your customers.
The following options are useless for a common usage of Dolibarr. But they are usefull if you plan to host / provide Dolibarr instances as Software As A Service (SAAS) to your customers.


*To aviod bas use of the emailing module, it is recommanded to set the option MAILING_NO_USING_PHPMAIL to 1 (See previously). Also You can complete the message visible by customers to your hotline by using the constant MAILING_SMTP_SETUP_EMAILS_FOR_QUESTIONS (See previously)
*To avoid bas use of the emailing module, it is recommanded to set the option MAILING_NO_USING_PHPMAIL to 1 (See previously). Also You can complete the message visible by customers to your hotline by using the constant MAILING_SMTP_SETUP_EMAILS_FOR_QUESTIONS (See previously)
 
* MAIN_EXTERNAL_SMTP_CLIENT_IP_ADDRESS: Set here the ip of list of ip where your Dolibarr instances are hosted. So when your customer go into the setup area of email, a message will explain him how to setup its SPF record for its email domain. This is to avoid to have its emails, sent from its Dolibarr instance, fails due to strict antispam rule of some emailing servers.
 
* MAIN_ALWAYS_CREATE_LOCK_AFTER_LAST_UPGRADE: If set, when you launch upgrades of your customer instances, you are sure that the upgrade process recreate automatically the file install.lock so the administration tools like install.php and repair.php can't be used on your customer instance (until the lock file is deleted).
 
* MAIN_FILECHECK_LOCAL_SUFFIX: If you offer a customized or patched version of Dolibarr, when the user will use the tool to chek the integrity of files, the default xml file name used for signature checking will be the official file provided by the Dolibarr team. To have the suggested signature file beeing your own file you can set ths constant to a suffix.
For example, set this to "'''-mysaassolution'''". So, when the user will use the file integrity tool, the default file to check for signature will be "'''/install/filelist-mysaassolution.xml'''" instead of "'''/install/filelist-10.0.2.xml'''". All you have to do is generate the signature file '''mysaassolution''' using the tool '''build/generate_filelist_xml.php''' and put this file into the install directory of your customer instance. Doing this, your customer, and yourself, will be able to check if a file was modified without beeing obfuscated by false alerts due to your customization or patches.