Jump to content
SpravkaCRM.ru - Ваш справочник по CRM
  • Files

  • Последние публикации

  • Последнее с форума

    • Ок, спасибо, SpravkaCRM.ru. Хотелось убедиться, что я правильно понимаю функционал этого ограничения. Наша очередь писем не рассылалась совсем, поэтому я решил, что превышение этого параметра блокирует рассылку. Это, к счастью, не так . В ходе дальнейших тестов мне удалось добиться нормального поведения очереди писем и заданий планировщика. При каждом срабатывании задания на рассылку почты отправлялась пачка писем, равная количеству, заданному параметром. А проблема была в планировщике, там зависла предыдущая задача в состоянии "running" и блокировала последующие задания. Так как время жизни этих заданий сутки(!) пришлось прибить её руками, примерно так: SELECT * FROM [ваша база].job_queue WHERE status != 'done'; //Получаем id
      UPDATE [ваша база].job_queue SET status = 'done', resolution = 'success' WHERE id = '[ставим сюда id ]'; А время жизни зависших заданий планировщика можно поменять в config_override.php, добавив/изменив параметр $sugar_config['jobs']['timeout'] = время в секундах, например 3600 (час).
    • Добрый день! при помощи этой настройки можно регулировать нагрузку как на собственный сервер, так и на почтовый сервер. Большое количество писем, если сервер не очень мощный, может привести к нехватке памяти и все встанет. Так же некоторые почтовые сервера имеют ограничения на кол-во отправляемых через них писем в течении какого то кол-ва времени (в рамках борьбы со спамом или предлагая бизнес-тарифы).  Для регулирования подобных вещей и применяется этот параметр
    • Добрый день. Так как тоже столкнулся с проблемами в работе рассылок, то добавлю свои вопросы сюда. Подскажите, уважаемые гуру, зачем вообще нужен параметр "Количество писем, отправляемых одномоментно при пакетной рассылке"? Как работает (должно работать) это ограничение, если писем в очереди больше? В нашем случае, когда такое случается, очередь перестаёт рассылаться вообще. Ни одного письма не уходит. Приходится отправлять письма принудительно. Это баг? Тогда как исправить? Какое значение порекомендуете? SuiteCRM 7.7.4 Спасибо!
    • Hello, I have followed the instructions but it does not work for me.
      I replaced the "YAHOO.widget.AutoComplete.prototype._updateValue = function (elListItem)" in the include / javascript / yui / build / autocomplete / autocomplete.js file.
      Can you support me or send me the files edits.
      Thanks
    • Всем привет! Хочу показать мой вариант решения следующей проблемы: Есть бизнес-процесс, который настроен на модуль "Контрагенты". В результате срабатывания бизнес-процесса должны создаться две записи: Запись в модуле "Обращения" Запись в модуле "Документы" Но вся сложность заключается в том, что и Обращение и Документ должны не просто добавиться в Контрагент, но и между собой сформировать связь. То есть зайдя потом в карточку созданного Обращения мы должны увидеть в сабпанели созданный Документ! Если очень упрощенно, то мой бизнес-процесс выглядит так: Как вы видите, у меня в действиях отмечен чекбокс "Связать с записью в контролируемом модуле". Этот чекбокс позволяет созданным записям находится в соответствующих сабпанелях Контрагента. Но вот Обращение с Документом между собой никак не хотели связываться! Как я не тестировал, что не пробовал, но без доработки CRM-системы чисто имеющимися средствами эту задачу решить не получилось. Я пожалуй не буду утомлять рассуждениями на тему "что же тут делать и как я пришел к конечному результату", а просто опишу то, что в итоге было сделано в CRM-системе, что позволило решить эту задачу: 1. Первое: Добавляем в модуль Контрагенты два новых поля: custom/Extension/modules/Accounts/Ext/Vardefs/custom_fields.tmp.php: <?php $dictionary['Account']['fields']['tmp_document_id'] = array ( 'required' => false, 'name' => 'tmp_document_id', 'vname' => 'LBL_TMP_DOCUMENT_ID', 'type' => 'id', 'massupdate' => 0, 'no_default' => false, 'comments' => '', 'help' => '', 'importable' => 'true', 'duplicate_merge' => 'disabled', 'duplicate_merge_dom_value' => 0, 'audited' => false, 'inline_edit' => true, 'reportable' => false, 'unified_search' => false, 'merge_filter' => 'disabled', 'len' => 36, 'size' => '20', 'source' => 'non-db', ); $dictionary['Account']['fields']['tmp_document'] = array ( 'required' => false, 'source' => 'non-db', 'name' => 'tmp_document', 'vname' => 'LBL_TMP_DOCUMENT', 'type' => 'relate', 'massupdate' => 1, 'no_default' => false, 'comments' => '', 'help' => '', 'importable' => 'true', 'duplicate_merge' => 'disabled', 'duplicate_merge_dom_value' => '0', 'audited' => false, 'inline_edit' => true, 'reportable' => true, 'unified_search' => false, 'merge_filter' => 'disabled', 'len' => '255', 'size' => '20', 'id_name' => 'tmp_document_id', 'ext2' => 'Documents', 'module' => 'Documents', 'rname' => 'name', 'quicksearch' => 'enabled', 'studio' => 'visible', ); $dictionary['Account']['fields']['tmp_case_id'] = array ( 'required' => false, 'name' => 'tmp_case_id', 'vname' => 'LBL_TMP_CASE_ID', 'type' => 'id', 'massupdate' => 0, 'no_default' => false, 'comments' => '', 'help' => '', 'importable' => 'true', 'duplicate_merge' => 'disabled', 'duplicate_merge_dom_value' => 0, 'audited' => false, 'inline_edit' => true, 'reportable' => false, 'unified_search' => false, 'merge_filter' => 'disabled', 'len' => 36, 'size' => '20', 'source' => 'non-db', ); $dictionary['Account']['fields']['tmp_case'] = array ( 'required' => false, 'source' => 'non-db', 'name' => 'tmp_case', 'vname' => 'LBL_TMP_CASE', 'type' => 'relate', 'massupdate' => 1, 'no_default' => false, 'comments' => '', 'help' => '', 'importable' => 'true', 'duplicate_merge' => 'disabled', 'duplicate_merge_dom_value' => '0', 'audited' => false, 'inline_edit' => true, 'reportable' => true, 'unified_search' => false, 'merge_filter' => 'disabled', 'len' => '255', 'size' => '20', 'id_name' => 'tmp_case_id', 'ext2' => 'Cases', 'module' => 'Cases', 'rname' => 'name', 'quicksearch' => 'enabled', 'studio' => 'visible', ); custom/Extension/modules/Accounts/Ext/Language/ru_RU.TMP.php: <?php $mod_strings['LBL_TMP_DOCUMENT'] = 'TMP.DOCUMENT'; $mod_strings['LBL_TMP_DOCUMENT_ID'] = 'TMP.DOCUMENT_ID'; $mod_strings['LBL_TMP_CASE'] = 'TMP.CASE'; $mod_strings['LBL_TMP_CASE_ID'] = 'TMP.CASE_ID'; Обращаю ваше внимание на то, что данные поля имеют параметр 'source' => 'non-db', что говорит о том, что эти поля исключительно расчетные, и не хранят значения в базе данных. 2. Второе. Добавляю Hook на добавление связи Контрагента с чем-либо: custom/Extension/modules/Accounts/Ext/LogicHooks/tmp.hooks.php: <?php $hook_array['after_relationship_add'][] = Array( 10, 'TMP Fields', 'custom/modules/Accounts/TMPLogicHooks.php', 'TMPLogicHooks', 'setTMPFields' ); custom/modules/Accounts/TMPLogicHooks.php: <?php /** * Created by PhpStorm. * User: crmhosting * Date: 01.06.2018 * Time: 15:52 */ class TMPLogicHooks { /** * Заполняем временные поля значениями * @param $bean * @param $event * @param $arguments */ function setTMPFields($bean, $event, $arguments) { if($arguments['module'] == 'Accounts' AND $arguments['related_module'] == 'Cases') { // Если сейчас связь Контрагента и Обращения $bean->tmp_case_id = $arguments['related_bean']->id; } elseif ($arguments['module'] == 'Accounts' AND $arguments['related_module'] == 'Documents') { // Если сейчас связь Контрагента и Документа $bean->tmp_document_id = $arguments['related_bean']->id; } } } Таким образом мы во время связи Контрагента с Обращением или Документом заполняем наши вспомогательные поля. 3. Третье. Делаем быстрое восстановление. Чтобы в системе применились все добавленные поля и хуки. 4. Четвертое. В Бизнес-процессе в действии добавления Документа указываем связь с Обращением через нашу переменную  tmp_case_id: Вот как теперь будет выглядеть бизнес-процесс: После срабатывания такого бизнес-процесса у создаваемого обращения появляется прямая связь с создаваемым документом. Что нам и было нужно.   Давайте теперь немного объясню что же у нас получилось: Мы в Контрагенте создали пару полей. Но не простых, а типа relate - это когда в текущем модуле есть связь с записью в другом модул Мы в Контрагенты добавили хук after_relationship_add, который будет срабатывать каждый раз, когда к Контрагенту будет добавляться связь с записью другого модуля В момент, когда срабатывает бизнес-процесс, в первую очередь создается Обращение, а затем добавляется связь этого обращения с Контрагентом, что приводит к срабатыванию нашего хука Внутри хука мы видим, что добавляется связь Контрагента и Обращения. Мы добавляем в поле Контрагента tmp_case_id айди созданного и добавляемого Обращения Все, Обращение создано и привязано к Контрагенту Далее по бизнес-процессу создается Документ Документ мало того, что привязывается к Контрагенту, так мы в бизнес-процессе еще прописали ему некую связь с Обращениями, и указали, что связать он должен по полю TMP.CASE (а это как раз наше поле tmp_case_id, которое мы заполнили в прошлый раз, когда добавляли связь с Обращением) Таким образом создаваемый документ связывается с ранее созданным Обращением. Ну и связь двухсторонняя: если привязали Документ к Обращению, значит и Обращение привязано к Документу. Profit! Если что не понятно, или есть предложения по реализации данной задачи другими способами, то буду рад пообщаться в комментариях.  
×