31,003
edits
Setup Other: Difference between revisions
Jump to navigation
Jump to search
m
→For SaaS / Cloud hosting integrators
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 972: | Line 972: | ||
*MAILING_LIMIT_SENDBYDAY ► This is a limit of number of emails, an instance can send. Note that this is not a hard limit; it is just the quantity that will be displayed on warnings on screen. For a real limit, this must be implemented into the system. | *MAILING_LIMIT_SENDBYDAY ► This is a limit of number of emails, an instance can send. Note that this is not a hard limit; it is just the quantity that will be displayed on warnings on screen. For a real limit, this must be implemented into the system. | ||
*MAILING_LIMIT_WARNING_PHPMAIL ► Set this value to a translation key. Then add translation keys into the instance so user will see a message when into the email setup page. For example, you can set a message to say ''Warning: To avoid abuse, when using default setup, you are restricted to 500 emails per day for all your application (account may be suspended in case of violation of this rule. You can setup application to use your own SMTP server for sending email so you want have no restriction at all (see menu Home-Setup-Emails)'' | |||
*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_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: | ||
| Line 988: | Line 986: | ||
*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'. | ||
*MAIN_HIDE_WARNING_TO_ENCOURAGE_SMTP_SETUP ► Set to 1 by default. You can set it to 0 to show a warning to encourage admin to set its own SMTP service. | |||
*MAIN_MIN_NB_ENABLED_MODULE_FOR_WARNING ► If set to N, the warning saying modules are not activated will be shown if number of activated module is < N (Having this variable not defined is same than having it set to 1). This may be usefull if you preinstall an application with some modules already loaded by default and you want to keep the warning to be sure the user will enable other modules he need, even if some modules are already enabed. | *MAIN_MIN_NB_ENABLED_MODULE_FOR_WARNING ► If set to N, the warning saying modules are not activated will be shown if number of activated module is < N (Having this variable not defined is same than having it set to 1). This may be usefull if you preinstall an application with some modules already loaded by default and you want to keep the warning to be sure the user will enable other modules he need, even if some modules are already enabed. | ||