Changes

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.

*CRON_DISABLE_KEY_CHANGE: When you provide an instance to a customer, you probably also add an entry in the cron of this user so Dolibarr batch and scheduler can work correctly. For security purpose, it may have a security key that is inside the command line into the cron entry and this entry must match the value defined into Dolibarr setup (setup of module 'Scheduled Jobs'). Because, a customer of a Saas platform will probably have no access to edit the cron file, it is also import that he has no way to edit the key into the Dolibarr setup, so the key in the cron command line will always match the key in Dolibarr setup, and the Dolibarr batches will executed without security errors. To be sure, the customer does not change the value, you can set this constant to 1 into the table [[Table_llx_const]].

*CRON_DISABLE_KEY_CHANGE ► When you provide an instance to a customer, you probably also add an entry in the cron of this user so Dolibarr batch and scheduler can work correctly. For security purpose, it may have a security key that is inside the command line into the cron entry and this entry must match the value defined into Dolibarr setup (setup of module 'Scheduled Jobs'). Because, a customer of a Saas platform will probably have no access to edit the cron file, it is also import that he has no way to edit the key into the Dolibarr setup, so the key in the cron command line will always match the key in Dolibarr setup, and the Dolibarr batches will executed without security errors. To be sure, the customer does not change the value, you can set this constant to 1 into the table [[Table_llx_const]].

*CRON_DISABLE_TUTORIAL_CRON: Disable the tutorial about how to install the cron script (on a SaaS hosting, this should be the system)

*CRON_DISABLE_TUTORIAL_CRON ► Disable the tutorial about how to install the cron script (on a SaaS hosting, this should be the system)

*To avoid bad use of the emailing module, it is recommended to set the option MAILING_NO_USING_PHPMAIL to 1 (This option is described previously). Also you can complete the message visible by customers when they try to setup the SMTP credentials of their Dolibarr by using the constant MAILING_SMTP_SETUP_EMAILS_FOR_QUESTIONS (This option is described previously). For example, you can point to a FAQ on your website.

*To avoid bad use of the emailing module, it is recommended to set the option MAILING_NO_USING_PHPMAIL to 1 (This option is described previously). Also you can complete the message visible by customers when they try to setup the SMTP credentials of their Dolibarr by using the constant MAILING_SMTP_SETUP_EMAILS_FOR_QUESTIONS (This option is described previously). For example, you can point to a FAQ on your website.

*MAIN_EXTERNAL_SMTP_CLIENT_IP_ADDRESS: (A better name of this option should be MAIN_EXTERNAL_MAIL_CLIENT_IP_ADDRESS). Set here the list of IPs where your Dolibarr instances are hosted. So when your customer go into the setup area of email:

*MAIN_EXTERNAL_SMTP_CLIENT_IP_ADDRESS ► (A better name of this option should be MAIN_EXTERNAL_MAIL_CLIENT_IP_ADDRESS). Set here the list of IPs where your Dolibarr instances are hosted. So when your customer go into the setup area of email:

** If he chose mail method, a message will explain him how to setup its SPF record for its email domain (showing the list of IP). This is to avoid to have its emails, sent from its Dolibarr instance, fails due to strict antispam rule of some emailing servers.

** If he chose mail method, a message will explain him how to setup its SPF record for its email domain (showing the list of IP). This is to avoid to have its emails, sent from its Dolibarr instance, fails due to strict antispam rule of some emailing servers.

** If he chose smtp method, a message will explain him the list of IP he can use if there is restriction on IP by the SMTP agent. If you also need to add a message to help SPF setup, see option MAIN_EXTERNAL_SMTP_SPF_STRING_TO_ADD.  

** If he chose smtp method, a message will explain him the list of IP he can use if there is restriction on IP by the SMTP agent. If you also need to add a message to help SPF setup, see option MAIN_EXTERNAL_SMTP_SPF_STRING_TO_ADD.  

*If you set a system limit on number of recipient, you can set some option to match the same values so users will be informed: MAIL_MAX_NB_OF_RECIPIENTS_IN_SAME_EMAIL ► Restrict sending of 1 email message to <code>x</code> recipients for same email message (x for To: + CC: + BCC:). If not defined, value is <code>10</code>. Required to fight against spamming that include 1000 recipients in 1 message. Note that MAIL_MAX_NB_OF_RECIPIENTS_TO_IN_SAME_EMAIL, MAIL_MAX_NB_OF_RECIPIENTS_CC_IN_SAME_EMAIL and MAIL_MAX_NB_OF_RECIPIENTS_BCC_IN_SAME_EMAIL are also available.

*If you set a system limit on number of recipient, you can set some option to match the same values so users will be informed: MAIL_MAX_NB_OF_RECIPIENTS_IN_SAME_EMAIL ► Restrict sending of 1 email message to <code>x</code> recipients for same email message (x for To: + CC: + BCC:). If not defined, value is <code>10</code>. Required to fight against spamming that include 1000 recipients in 1 message. Note that MAIL_MAX_NB_OF_RECIPIENTS_TO_IN_SAME_EMAIL, MAIL_MAX_NB_OF_RECIPIENTS_CC_IN_SAME_EMAIL and MAIL_MAX_NB_OF_RECIPIENTS_BCC_IN_SAME_EMAIL are also available.

*MAIN_EXTERNAL_SMTP_SPF_STRING_TO_ADD: Set here the string to add in the SPF record This string will be shown into a help message when the user in in the setup of email page and has choose a method using an external SMTP server.

*MAIN_EXTERNAL_SMTP_SPF_STRING_TO_ADD ► Set here the string to add in the SPF record This string will be shown into a help message when the user in in the setup of email page and has choose a method using an external SMTP server.

*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_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 and MAIN_FILECHECK_LOCAL_EXT: If you offer a customized or patched version of Dolibarr, when the user will use the tool to check the integrity of files, the default xml file name used for signature checking will be the official file provided by the Dolibarr team, so it does not includes your own changes. To have the suggested signature file being your own file, you can set the constant MAIN_FILECHECK_LOCAL_SUFFIX 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-10.0.2-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 being disturbed by false alerts due to your customized files or patches (they will be included in the signature used for check). Also, if you want to zip the customized signature file into "'''/install/filelist-10.0.2-mysaassolution.xml.zip'''", you can set the constant MAIN_FILECHECK_LOCAL_EXT to '.zip'.

*MAIN_FILECHECK_LOCAL_SUFFIX and MAIN_FILECHECK_LOCAL_EXT ► If you offer a customized or patched version of Dolibarr, when the user will use the tool to check the integrity of files, the default xml file name used for signature checking will be the official file provided by the Dolibarr team, so it does not includes your own changes. To have the suggested signature file being your own file, you can set the constant MAIN_FILECHECK_LOCAL_SUFFIX 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-10.0.2-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 being disturbed by false alerts due to your customized files or patches (they will be included in the signature used for check). Also, if you want to zip the customized signature file into "'''/install/filelist-10.0.2-mysaassolution.xml.zip'''", you can set the constant MAIN_FILECHECK_LOCAL_EXT to '.zip'.

*SYSLOG_DISABLE_LOGHANDLER_SYSLOG: Set this to 1 to disable usage of syslog (having all customer instances logging in the same system file is not a good idea).

*SYSLOG_DISABLE_LOGHANDLER_SYSLOG ► Set this to 1 to disable usage of syslog (having all customer instances logging in the same system file is not a good idea).

*WEBSITE_REPLACE_INFO_ABOUT_USAGE_WITH_WEBSERVER: Put here a text a a translation key of a text to show when the user will use the feature "Deploy" when he want to deploy a website done with Dolibarr CMS. So you can, for example, show him a message that this feature is not part of is subscription and putting a website online may need a complementary subscription.

*WEBSITE_REPLACE_INFO_ABOUT_USAGE_WITH_WEBSERVER ► Put here a text a a translation key of a text to show when the user will use the feature "Deploy" when he want to deploy a website done with Dolibarr CMS. So you can, for example, show him a message that this feature is not part of is subscription and putting a website online may need a complementary subscription.