processIssueAutoMove - що за дію в кроні, за що відчує і як впливати на час його виконання налаштуваннями

Це все ваші налаштування, на кшталт "змінити етап залежно від значення..", які спрацьовують раз на хвилину. Як скоротити час роботи - виконувати налаштування правильно, включати оновлення раз на годину/день, там де не потрібно так часто перевіряти. (не знаю, чи буде дія реально працювати на денному/годинному кроні, але навантаження явно зменшить, тому що наприклад, не раз на хвилину по 40 секунд потрібно буде обробляти процеси, а тільки раз на годину постратити 40 секунд, тобто раз на годину крон працюватиме трохи довше) Чим більше процесів, у статусах, де виконується така перевірка, тим довше працює, тому прибрати/замінити автоматизацію на етапах, де буде багато процесів, де можливо - зробити зміну по тригерах (наприклад, якщо значення передається з іншого процесу, а перевірка разів на хвилину виконується в поточному, то можна відразу змінити статус), замість перевірки раз на хвилину

[quote] Суханицький Андрій Інтегратор Клієнт Integrator CRM написав: Це все ваші налаштування, на кшталт "змінити етап залежно від значення..", які спрацьовують раз на хвилину. Як скоротити час роботи - виконувати налаштування правильно, включати оновлення раз на годину/день, там де не потрібно так часто перевіряти. (не знаю, чи буде дія реально працювати на денному/годинному кроні, але навантаження явно зменшить, тому що наприклад, не раз на хвилину по 40 секунд потрібно буде обробляти процеси, а тільки раз на годину постратити 40 секунд, тобто раз на годину крон працюватиме трохи довше) Чим більше процесів, у статусах, де виконується така перевірка, тим довше працює, тому прибрати/замінити автоматизацію на етапах, де буде багато процесів, де можливо - зробити зміну по тригерах (наприклад, якщо значення передається з іншого процесу, а перевірка разів на хвилину виконується в поточному, то можна відразу змінити статус), замість перевірки раз на хвилину [/quote] Андрію, дякую за відповідь, але рекомендація анонімної качки виявилася робочою

[quote] anonymous duck OneBox production Співробітник писав/ла: На жаль, Андрій частково ввів вас в оману. Вказаний процес для користувачів, у яких стоїть налаштування "Автоматично переносити невиконані бізнес-процеси на наступний день", переносить завдання на наступний день. А ось вже наскільки швидко завдання переносяться залежить від їх кількості та налаштувань бп. Якщо завдання переносяться довго, ймовірно стоять дії, які роблять щось при збереженні процесів. [/quote] Дякую! допомогло. правда довелося трохи покрутити із запитами... річ у тому, що це завдання processIssueAutoMove зовсім не враховує видалений контакт чи ні, співробітник він чи ні, заблокований він чи ні тощо. Виходить, ноги ростуть з того, що... був співробітник, потім звільнився, його заблокували... на ньому зависла купа завдань і навіть при великому бажанні буде дуже проблематично знайти всі контакти, у яких ця опція включена... але я знайшов. ... якщо кому потрібно буде - маякуйте, поділюсь sql запитом))) До речі, час роботи крона тепер менше 60 сек))))

[quote] Перегиняк Олександр ФОП Перегіняк О.П. Клієнт Oneboxconsulting (інтегратор) писав/ла: на ньому зависло купа завдань [/quote] ймовірно у нього були якісь марні для бізнесу завдання, на мою думку такого бути не повинно [quote] Перегиняк Олександр ФОП Перегіняк О.П. Клієнт Oneboxconsulting (інтегратор) писав/ла: якщо кому потрібно буде - маякуйте, поділюсь sql запитом [/quote] за такі речі можна злетіти з технічної підтримки

[quote] anonymous duck OneBox production Співробітник писав/ла: за такі речі можна злетіти з технічної підтримки [/quote] а ви знаєте, як я це робив? зауважте, я ж не писав про те, що використовував php my admin або ще щось ))). Ну та гаразд, функціонал конструктор звітів розглянемо будь-який раз ))) і так, думаю навіть за необдумане використання дій у бізнес-процесах теж можна позбавляти тих підтримки, бо ними можна так сервак захитати, що мало не здасться. в порівнянні з цим використання sql-запитів до таблиці буде сущим пустощом.

Варіантів як зробити запит до бази не так багато. [quote] Перегиняк Олександр ФОП Перегіняк О.П. Клієнт Oneboxconsulting (інтегратор) писав/ла: Ну та гаразд, функціонал конструктор звітів розглянемо будь-який інший раз [/quote] я вам його кодил, думаю не потрібно розповідати як він працює) Втім я до того, що якщо вже у вас є доступ до бд, то не потрібно "підштовхувати" лазити туди іншим, тому що в більшості випадків це може призвести до жалюгідних наслідків, тому що одним запитом можна зробити помилку.

[quote] anonymous duck OneBox production Співробітник писав/ла: Варіантів як зробити запит до бази не так багато. [quote] Перегиняк Олександр ФОП Перегіняк О.П. Клієнт Oneboxconsulting (інтегратор) писав/ла: Ну та гаразд, функціонал конструктор звітів розглянемо будь-який інший раз [/quote] я вам його кодил, думаю не потрібно розповідати як він працює) Втім я до того, що якщо вже у вас є доступ до бд, то не потрібно "підштовхувати" лазити туди іншим, тому що в більшості випадків це може призвести до жалюгідних наслідків, тому що одним запитом можна зробити помилку. [/quote] окей, більше не буду. тільки якщо мене попросять, хоча знаєте... мені здається ви перебільшуєте щодо небезпеки доступу до БД через конструктор. Дивіться, навіть у самій нещасній Престі є з адмінки доступ до бази даних .. і люди як би користуються .... але як не крути, ви власники продукту і вам вирішувати, чи варто вичинки овчинка чи ні. Як на мене, наявність такого зручного інструменту доступу до даних допоможе підвищити інтерес до продукту. я як людина, це минула, можу навіть це гарантувати)))

Мені здається, що людям потрібно давати підніматися на кілька рівнів вище ніж написання запитів у бд. Вміти писати запити в бд це звичайно круто, але це дуже специфічна навичка, якою володіє 0.01% народу на планеті. А ось поставити десь галочку (грубо) або вибрати поле це вже трохи простіше. Сенс у тому що писати код або запити в базу це круто, але ще крутіше не опускатися на рівень коли ця навичка знадобиться для налаштування будь-якої системи. У тому ж бітриксі наприклад взагалі можна php код стартувати з адмінки, але це не означає, що це добре і тим більше корисно (і взагалі не факт, що скрипти, які ти там пишеш краще, ніж сам код бітрикса або модулів, які ти там можеш підключити). Це потрібно одному відсотку людей, які знають цей php. Але швидше за все якщо ти ведучи свій інтернет магазин/налаштовуючи систему, сам починаєш лізти в код - швидше за все в житті ти робиш щось не те. Тобто. ти як би і кодити нормально не можеш, але й бізнес не ведеш (витрачаєш час на те, щоб в адмінці код якийсь написати). Аналогію можна навести з усіма улюбленими автомобілями. Звичайно добре знати як працює двигун, вміти його розібрати - але навіщо, якщо ти не автомеханік витрачати 2 дні щоб розібрати і полагодити двигун якщо можна відігнати його на сто і потім забрати, попрацювавши наприклад той же час і відбивши витрати на ремонт і заробивши зверху . Кожен повинен займатися своєю справою, якщо починаєш займатися кількома відразу - швидше за все добре робити жодне не вийде. Коротше не вчіть користувачів лізти "під капот" боксу)

[quote] anonymous duck OneBox production Співробітник писав/ла: Мені здається, що людям потрібно давати підніматися на кілька рівнів вище ніж написання запитів у бд. Вміти писати запити в бд це звичайно круто, але це дуже специфічна навичка, якою володіє 0.01% народу на планеті. А ось поставити десь галочку (грубо) або вибрати поле це вже трохи простіше. Сенс у тому що писати код або запити в базу це круто, але ще крутіше не опускатися на рівень коли ця навичка знадобиться для налаштування будь-якої системи. У тому ж бітриксі наприклад взагалі можна php код стартувати з адмінки, але це не означає, що це добре і тим більше корисно (і взагалі не факт, що скрипти, які ти там пишеш краще, ніж сам код бітрикса або модулів, які ти там можеш підключити). Це потрібно одному відсотку людей, які знають цей php. Але швидше за все якщо ти ведучи свій інтернет магазин/налаштовуючи систему, сам починаєш лізти в код - швидше за все в житті ти робиш щось не те. Тобто. ти як би і кодити нормально не можеш, але й бізнес не ведеш (витрачаєш час на те, щоб в адмінці код якийсь написати). Аналогію можна навести з усіма улюбленими автомобілями. Звичайно добре знати як працює двигун, вміти його розібрати - але навіщо, якщо ти не автомеханік витрачати 2 дні щоб розібрати і полагодити двигун якщо можна відігнати його на сто і потім забрати, попрацювавши наприклад той же час і відбивши витрати на ремонт і заробивши зверху . Кожен повинен займатися своєю справою, якщо починаєш займатися кількома відразу - швидше за все добре робити жодне не вийде. Коротше не вчіть користувачів лізти "під капот" боксу) [/quote] вірно говорите, але як ви розумієте, завжди і скрізь є одне АЛЕ, іноді навіть не одне... для мене, як аналітика в минулому, правило №1 облікової системи - все що в систему введено має бути з неї виведено для можливості обліку та аналізу та дуже бажано робити це швидко 1. на даний момент бокс, своїм функціоналом цього не дозволяє з тієї причини, що або немає функціонала, або він дуже незручний, незрозумілий, заплутаний, а якщо замовити розробку свого звіту, то за час реалізації потреба в даних або відпаде, або вимагатиме нових уточнень. загалом, варто здати потрібний звіт, як замовник попросить додати щось нове. щоразу звертатися до вас за цим - значить нескінченно зловживати терпінням замовника та його фінансами. рано чи пізно це все закінчиться 2. доступ до даних повинен бути відносно легкий ... те, що описали ви, про галочки правильно, але питання як зробити так, щоб не потонути в цих галочках? у звітах це навряд чи спрацює. навіть упевнений, що не спрацює 3. на рахунок конструкторів звітів... не знаю, чи ви знайомилися з функціоналом конструктора запитів в 1с і системою компонування даних. якщо ні можемо подивитися якось разом. Як на мене, треба визнати, що там це реалізовано досить зручно. тобто. можна писати запит не використовуючи SQL (саме те, про що ви й кажете - тикаєш, тягаєш, встановлюєш зв'язки і в результаті отримуєш будь-які дані в будь-якій формі). Ідея власне не нова, такі ж конструктори є і в іншому софті по роботі з базами даних 4. те, що я пишу запити це не через те, що я такий супер кодер і роблю це заради фана... швидше навпаки, через безвихідь бо я розумію, що наздогнати функціонал, аналогічний п.3 буде ХХХ годин програмінгу або потрібно знайти якийсь софт і впровадити його в бокс. у будь-якому випадку це велика сума грошей, і я не знаю клієнтів, які були б готові за нього заплатити 5. якщо вам цікаво, то можемо подумати над тим, щоб зробити окрему програму для боксу - конструктор запитів, в якому зможемо реалізувати саме те, про що пишете ви (можливість отримати дані з потрібних таблиць без використання програмування на sql). Впевнений, що така програма набуде популярності.

Я вас почув і зрозумів. Я зацікавлений попрацювати над вказаним у 5 пункті. Вам буде зручно, якщо я напишу вам наприклад, в телеграм на вказаний на форумі номер телефону?

[quote] anonymous duck OneBox production Співробітник писав/ла: Я вас почув і зрозумів. Я зацікавлений попрацювати над вказаним у 5 пункті. Вам буде зручно, якщо я напишу вам наприклад, в телеграм на вказаний на форумі номер телефону? [/quote] так звичайно