Идеи пользователя 39858
Добавьте, плз, давно нужна предобработка полей задания.
Раньше была отличная возможность выбрать сабж, а не перетыкивать каждого сотрудника отдела, если дочерние отделы не нужны. В современном BX.SocNetLogDestination, который используется не только в этом модуле, эта возможность, непонятно почему, потеряна.
Какой смысл перебирать мышкой 50 сотрудников отдела, когда раньше это можно было сделать одним флажком? (группкод D, а не DR)
зы. И да, если уж решили использовать этот диалог в бизнес-процессах, так реализуйте до конца поддержку того же сохранения последних выбранных пользователей.
Какой смысл перебирать мышкой 50 сотрудников отдела, когда раньше это можно было сделать одним флажком? (группкод D, а не DR)
зы. И да, если уж решили использовать этот диалог в бизнес-процессах, так реализуйте до конца поддержку того же сохранения последних выбранных пользователей.
Часто сотрудники одного подразделения выполняют одинаковые функции и могут помогать друг другу, подменять и т.п. И это нормальная работа и не требует участия руководителя.
Сделайте новую опцию делегирования в заданиях - "Подразделение" (CBPTaskDelegationType::Department (int 3)), чтобы сотрудники одного подразделения могли делегировать задания друг другу без привлечения руководства.
На возможный вопрос: "Ну есть же тип "Всем сотрудникам", почему не использовать его?" отвечу сразу - небезопасно, можно по ошибке делегировать чувствительные данные совсем не туда.
Сделайте новую опцию делегирования в заданиях - "Подразделение" (CBPTaskDelegationType::Department (int 3)), чтобы сотрудники одного подразделения могли делегировать задания друг другу без привлечения руководства.
На возможный вопрос: "Ну есть же тип "Всем сотрудникам", почему не использовать его?" отвечу сразу - небезопасно, можно по ошибке делегировать чувствительные данные совсем не туда.
Пока у всех дам истерика от срыва покровов, у меня логичный и закономерный вопрос - где настройка отображения года рождения, как было в профиле в соцсети?
Пока все, кого почти десять лет приучали, что указывать ДР на портале не зазорно, так как год не отображается, не съели, когда новый профиль показал всё без прикрас, пришлось делать хак.
и
Пока все, кого почти десять лет приучали, что указывать ДР на портале не зазорно, так как год не отображается, не съели, когда новый профиль показал всё без прикрас, пришлось делать хак.
/bitrix/js/ui/entity-editor/js/control.js [4966]:
var dateFormat = "j F Y";
if(BX.prop.getBoolean(this._schemeElement.getData(), "hideYear", false))
{
dateFormat = "j F";
}
value = BX.date.format(dateFormat, BX.parseDate(value));
|
/bitrix/modules/intranet/lib/component/userprofile/form.php [120]:
"data" => array("enableTime => false, "hideYear" => true);
|
Добавьте событие перед сохранением аттачей почты на диск, хочется возможность отменить эту свалку цивилизованным методом.
Серьёзно, нафига этот неконтролируемый бардак? При привязке писем к CRM, мало того, что аттачи дублируются в CRM, так ещё и дублируются на диск. В результате там какая-то адовая помойка из всякого хлама аттачей, включая всякие служебные картинки из писем. Развлечение - почисти диск. Если надо кому-то что-то сохранить на диск для дальнейшего использования - так дайте возможность это сделать вручную для тех файлов, которые реально нужны юзеру.
И "дублируются" - одно из ключевых слов! Это не ссылка на исходный файл, это дубль файла. В итоге, при привязке письма к CRM один файл из аттача превращается в три (один в письме, один в CRM и один на диске). Место на диске продавать надо, что ли?
Конечно, тут вообще подход менять надо, но хотя бы дайте событие.
Серьёзно, нафига этот неконтролируемый бардак? При привязке писем к CRM, мало того, что аттачи дублируются в CRM, так ещё и дублируются на диск. В результате там какая-то адовая помойка из всякого хлама аттачей, включая всякие служебные картинки из писем. Развлечение - почисти диск. Если надо кому-то что-то сохранить на диск для дальнейшего использования - так дайте возможность это сделать вручную для тех файлов, которые реально нужны юзеру.
И "дублируются" - одно из ключевых слов! Это не ссылка на исходный файл, это дубль файла. В итоге, при привязке письма к CRM один файл из аттача превращается в три (один в письме, один в CRM и один на диске). Место на диске продавать надо, что ли?
Конечно, тут вообще подход менять надо, но хотя бы дайте событие.
Недавно попросили сделать отчёт по завершённым за определённый месяц задачам.
Был удивлён, что за пять (или уже 6?) лет отчёты в задачах не научились нормальному фильтру по датам задачи - интервал невозможен, только пляска от одной конкретной даты, в результате чего приходится делать двойной фильтр по параметру, не всегда понятный пользователям (Дата завершения "больше или равно" и Дата завершения "меньше или равно")
Был удивлён, что за пять (или уже 6?) лет отчёты в задачах не научились нормальному фильтру по датам задачи - интервал невозможен, только пляска от одной конкретной даты, в результате чего приходится делать двойной фильтр по параметру, не всегда понятный пользователям (Дата завершения "больше или равно" и Дата завершения "меньше или равно")
Добавьте вывод заголовка активити в список заданий (т.е. хранение в b_bp_task).
Зачем? Чтобы пользователям можно было сортировать/фильтровать по этому полю и вообще легко ориентироваться, о каком же из заданий в рамках бизнес-процесса идёт речь.
Для руководителей вполне обычно желание посмотреть статистику, сколько заданий какого типа по определённому процессу выполнил сотрудник.
Не путать с названием задания, это разные вещи и название не подходит для этих целей.
Например, заголовок действия "Утверждение документа" и он неизменен от процесса к процессу. Тогда как название "Утвердить <документ такой-то>" (либо вовсе "<документ такой-то> требует утверждения") и в каждом процессе <документ такой-то> свой, соответственно отфильтровать/отсортировать однотипные задания нельзя.
Сейчас в b_bp_task хранится только ACTIVITY_NAME (id действия в шаблоне), но его человекопонятное значение приджоинить неоткуда - ни джоин b_bp_tracking (неоправданно дорогой запрос), ни извлечение из экземпляра процесса (кошмарно ресурсоёмко, к тому же экземпляр будет удалён по завершении), ни извлечение из шаблона процесса (ресурсоёмко и может быть изменён) разумным считать нельзя.
Зачем? Чтобы пользователям можно было сортировать/фильтровать по этому полю и вообще легко ориентироваться, о каком же из заданий в рамках бизнес-процесса идёт речь.
Для руководителей вполне обычно желание посмотреть статистику, сколько заданий какого типа по определённому процессу выполнил сотрудник.
Не путать с названием задания, это разные вещи и название не подходит для этих целей.
Например, заголовок действия "Утверждение документа" и он неизменен от процесса к процессу. Тогда как название "Утвердить <документ такой-то>" (либо вовсе "<документ такой-то> требует утверждения") и в каждом процессе <документ такой-то> свой, соответственно отфильтровать/отсортировать однотипные задания нельзя.
Сейчас в b_bp_task хранится только ACTIVITY_NAME (id действия в шаблоне), но его человекопонятное значение приджоинить неоткуда - ни джоин b_bp_tracking (неоправданно дорогой запрос), ни извлечение из экземпляра процесса (кошмарно ресурсоёмко, к тому же экземпляр будет удалён по завершении), ни извлечение из шаблона процесса (ресурсоёмко и может быть изменён) разумным считать нельзя.
Добавьте, плз, передачу $eventParameters задания, иначе очень сложно добираться до данных в обработчике.
Взять тот же комментарий пользователя к заданию - попробуйте его потом выцепить в обработчике... В b_bp_task_user комментарии отсутствуют, доставать из b_bp_task_history однозначно нельзя (нет привязки к id задания, только ACTION_NAME, к которому привязка неоднозначна, так как одно активити в течение процесса может выполняться несколько раз, да и вообще... выцеплять комментарий из процесса - ... Плюс всё это ресурсоёмко, тогда как все данные совсем рядом с вызовом обработчика и передать их туда - не проблема)
Либо добавьте комментарий в b_bp_task_user. А почему нет? Комментарии используются для всех заданий и порой они не менее, а то и более важны, нежели нажатая кнопка (статус выполнения).
Зачем?: Чтобы иметь возможность сохранять и выдавать пользователям реально значимую информацию о выполнении процесса. Например, при согласовании документов значимой информацией является как раз кто, когда, с каким результатом (утвердил, отклонил) и с каким комментарием выполнил задание:
PS. На текущий момент уже более 7 лет использую кастомные задания, которые пишут в отдельную таблицу результат задания (наименование выбранной операции/кнопки, для простой интерпретации) и комментарий. Применение - вывод различных отчётов и листов согласования к процессам. В штатном функционале этого не сделать.
Сохранение истории заданий в b_bp_task_user вы в каком-то виде сделали несколько лет назад, добавив статус задания, вместо его удаления, но этого недостаточно, нужны как минимум комментарии, а лучше ещё и наименование выбранной операции, а не только как сейчас - константы CBPTaskUserStatus (Почему? Потому что это лучше отражает суть, мы можем использовать задание утверждения для запроса, например, "Сделано/Не сделано", "Продолжить/Прекратить", и видеть вместо этих значений в результате только "Одобрил/Отклонил" - согласитесь, суть не отражает вовсе. Возможность задания текста кнопки помогает только пользователям при выполнении задания, но совершенно не помогает при его интерпретации в логе).
Взять тот же комментарий пользователя к заданию - попробуйте его потом выцепить в обработчике... В b_bp_task_user комментарии отсутствуют, доставать из b_bp_task_history однозначно нельзя (нет привязки к id задания, только ACTION_NAME, к которому привязка неоднозначна, так как одно активити в течение процесса может выполняться несколько раз, да и вообще... выцеплять комментарий из процесса - ... Плюс всё это ресурсоёмко, тогда как все данные совсем рядом с вызовом обработчика и передать их туда - не проблема)
Либо добавьте комментарий в b_bp_task_user. А почему нет? Комментарии используются для всех заданий и порой они не менее, а то и более важны, нежели нажатая кнопка (статус выполнения).
Зачем?: Чтобы иметь возможность сохранять и выдавать пользователям реально значимую информацию о выполнении процесса. Например, при согласовании документов значимой информацией является как раз кто, когда, с каким результатом (утвердил, отклонил) и с каким комментарием выполнил задание:
| Пользователь | Время | Результат | Комментарий |
| Начальник отдела | 27.10.18 12:20 | Утвердил | |
| Директор | 28.10.18 14:30 | Отклонил | Вы офигели? Дорого |
PS. На текущий момент уже более 7 лет использую кастомные задания, которые пишут в отдельную таблицу результат задания (наименование выбранной операции/кнопки, для простой интерпретации) и комментарий. Применение - вывод различных отчётов и листов согласования к процессам. В штатном функционале этого не сделать.
Сохранение истории заданий в b_bp_task_user вы в каком-то виде сделали несколько лет назад, добавив статус задания, вместо его удаления, но этого недостаточно, нужны как минимум комментарии, а лучше ещё и наименование выбранной операции, а не только как сейчас - константы CBPTaskUserStatus (Почему? Потому что это лучше отражает суть, мы можем использовать задание утверждения для запроса, например, "Сделано/Не сделано", "Продолжить/Прекратить", и видеть вместо этих значений в результате только "Одобрил/Отклонил" - согласитесь, суть не отражает вовсе. Возможность задания текста кнопки помогает только пользователям при выполнении задания, но совершенно не помогает при его интерпретации в логе).
Данных в событии не хватает для нормальной обработки.
В случае, если стреляет событие на добавление комментария или даже апдейт задачи - в обработчике не имеем даже ID задачи, не говоря про остальное.
В то же время выше вызова обработчиков событий имеем массив $message, в котором имеется вся необходимая информация и даже больше. Только вот в событие отправляется только куцая и местами бесполезная его часть.
Желательно отправлять в обработчик сам $message, а не $message['EVENT_DATA'].
Схожая идея пятилетней давности -
В случае, если стреляет событие на добавление комментария или даже апдейт задачи - в обработчике не имеем даже ID задачи, не говоря про остальное.
В то же время выше вызова обработчиков событий имеем массив $message, в котором имеется вся необходимая информация и даже больше. Только вот в событие отправляется только куцая и местами бесполезная его часть.
Желательно отправлять в обработчик сам $message, а не $message['EVENT_DATA'].
Схожая идея пятилетней давности -
Инструмент вроде бы хороший, но недокументированный и местами непродуманный.
Что касательно сабжа - похоже, и сами понимаете, что механизм нужен, но реализовывали "на местах" и это криво - возможность проверки отключения сделали уже в самих провайдерах, т.е., для этой проверки всё равно подключается модуль, инициализируется провайдер, что, в общем-то, нафиг не нужно с точки зрения ресурсов. К тому же, такая возможность не во всех провайдерах (интранет вот нельзя отключить вовсе), а сами параметры для отключения не соответствуют ID провайдеров (например, для групп пользователей с ID group это groups, для socnetgroup это socnetgroups, да я себе чуть мозг не сломал, пытаясь понять, почему у меня не получается их убрать из диалога, кто придумал там эту "s" на конце?
)
Сделайте, пожалуйста, хотелось бы использовать этот удобный диалог, но зачастую ряд провайдеров не нужен вовсе.
Что касательно сабжа - похоже, и сами понимаете, что механизм нужен, но реализовывали "на местах" и это криво - возможность проверки отключения сделали уже в самих провайдерах, т.е., для этой проверки всё равно подключается модуль, инициализируется провайдер, что, в общем-то, нафиг не нужно с точки зрения ресурсов. К тому же, такая возможность не во всех провайдерах (интранет вот нельзя отключить вовсе), а сами параметры для отключения не соответствуют ID провайдеров (например, для групп пользователей с ID group это groups, для socnetgroup это socnetgroups, да я себе чуть мозг не сломал, пытаясь понять, почему у меня не получается их убрать из диалога, кто придумал там эту "s" на конце?
)Сделайте, пожалуйста, хотелось бы использовать этот удобный диалог, но зачастую ряд провайдеров не нужен вовсе.
Честно говоря, думал, что по клику на какое-нибудь значение в скобках я сразу буду перекинут к редактированию именно этого поля.
По-моему, это было бы удобно и логично.
Не понимаю, что мешает сделать нативные документы с табличной частью? Особенно после появления хайлад ИБ, которые практически напрашиваются для этой цели (как лёгкие таблицы для табличной части).
Необходимость документов с табличной частью вроде как очевидна и используется много где, но это всё частные реализации под конкретные нужды (счета, заказы итп), а вот в плане предоставления пользователям (админам) возможности легко создавать и конструировать такие документы (элементы в данном контексте) - ой.
Необходимость документов с табличной частью вроде как очевидна и используется много где, но это всё частные реализации под конкретные нужды (счета, заказы итп), а вот в плане предоставления пользователям (админам) возможности легко создавать и конструировать такие документы (элементы в данном контексте) - ой.
Всех устраивающего механизма прав в задачах всё равно не сможете сделать, кому-то нужно, чтобы никто, кроме постановщика ничего не мог сделать, кому-то наоборот, надо дать более широкие права исполнителям и наблюдателям, чтобы не просить по каждому чиху постановщика внести изменения (ну удобно просить директора - "а добавьте, пожалуйста, в наблюдатели ещё 5 человек по этой вот, этой и тому десятку задач" ???)
Сделайте подобие ролевых прав в настройках модуля, чтобы админ мог сам определить, какие операции с задачей может делать постановщик, исполнитель, соисполнитель и наблюдатели.
Сделайте подобие ролевых прав в настройках модуля, чтобы админ мог сам определить, какие операции с задачей может делать постановщик, исполнитель, соисполнитель и наблюдатели.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
