31,003
edits
Setup Other: Difference between revisions
m
→For SaaS / Cloud hosting integrators
m (MAIN_COUNTRIES_IN_EEC - ad a precision) |
Tag: 2017 source edit |
||
| Line 967: | Line 967: | ||
*CRON_WARNING_DELAY_HOURS ► Set this value to the frequency set for the cron script (so a warning will be shown to user to warn it about max frequency of its scheduled jobs) | *CRON_WARNING_DELAY_HOURS ► Set this value to the frequency set for the cron script (so a warning will be shown to user to warn it about max frequency of its scheduled jobs) | ||
*To avoid bad use of the emailing module, it is recommended to set | *MAILING_NO_USING_PHPMAIL ► To avoid bad use of the emailing module, it is recommended to set this option 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. | ||
*If you set a | *MAIL_MAX_NB_OF_RECIPIENTS_IN_SAME_EMAIL ► If you set a limit on number of recipient on your system, 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 a ton of 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. 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. | |||
*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). | ||