Михаил, можете описать структуру в AD, которая корректно загрузится в КП с адекватной иерархией подразделений? Или такового до сих пор нет?
спасибо на лайк не намажешь
|
эм. Попытаюсь обрисовать структуру в АД.
В AD иерархия такая:
В общем, дерево вложенных юнитов. Я ожидал, что такую же иерархию мне построит и в битриксе после импорта, однако фокус не удался. Все подразделения просто лежат рядом, а не Подразделение1 и у него два дочерних - Подразделение2,3. Теперь в задумчивости, что делать. зы. мультидепартаментность не использую.
спасибо на лайк не намажешь
|
|||
|
|
|
|
Кстати. А как насчёт разнесения структуры по OU вложенным. Протестировал ради интереса, так как возможно предстоит задача подключения к AD - все подразделения свалились в верхний уровень, невзирая на структуру в AD. Т.е. подразделения дёрнулись, юзеры тоже, но вот иерархии подразделений нема, всё в корне.
спасибо на лайк не намажешь
|
|
|
|
|
спасибо на лайк не намажешь
|
|||
|
|
|
|
Вопрос не ясен. Какие задачи? Имеются ввиду "задания" бизнес-процессов?
Например, у вас запущен какой-то там бизнес-процесс, висит задание пользователю, вы его удалите... И что дальше? Бизнес-процессу что делать? Он ожидал реакции пользователя на задание, ввода каких-то данных. А вы его прибили. Аминь. В общем, без обработки данных из задания это выглядит бессмысленным. Разве что стопорить процесс целиком.
спасибо на лайк не намажешь
|
|
|
|
|
|
Т.е. поле комментарий какого-то конкретного действия? Это зависит, хранит ли действие это поле. Запрос дополнительной информации - по-моему не хранит, просто пишет в лог и всё. А вообще, чтобы вытаскивать инфу с определённого действия, точно не помню, но что-то вроде
где $actId - ид активити (можно посмотреть в настройке действия в шаблоне, нажав ссылку "ИД" вверху. Можно и свой ид понятный задать, во время конструирования шаблона БП в дизайнере. $targetField - соответственно нужное вам поле (свойство) активити. список свойств активити можно посмотреть непосредственно в коде этого активити, в конструкторе.
спасибо на лайк не намажешь
|
|||
|
|
|
|
для параметров - сперва получить корневое действие:
потом общаться с ними как
т.е. есть параметр "blabla", работаем с ним как
вроде не наврал. про комментарий не понял.
спасибо на лайк не намажешь
|
|||||||
|
|
|
|
Во-первых, спасибо, что создали тему и проявляете интерес к "общественному мнению".
Ну и далее: 1. События для задач (создание/изменение/завершение итп) для возможности навешивать свой функционал в нужных местах. 2. Постановка задачи в календарь/сверка с календарём при добавлении задачи. 3. Дополнительное поле (аналитика) для задач. Для возможности группировки задач/выборки данных по этой дополнительной аналитике. Например, есть группы задач относящиеся к какой-то определённой категории (представим себе, что у нас появился, пусть, документооборот на задачах), хотелось бы отделять зёрна от плевел, хотим посмотреть/построить отчёт по задачам только в пределах документооборота - строим. Хотим обычные - смотрим только обычные. Хотим все - смотрим все. Сделать в штатном компоненте поддержку этой аналитики (встроить в меню-фильтр задач, как дополнительные фильтры, типа как сейчас статусы). Блин. Что-то написать нормально не могу, но думаю мысль понятна. 4. Произвольные свойства задач. Спорно, наверное. Это мои тараканы, связанные с замещением "заданий" бизнес-процессов задачами. Навскидку не могу придумать, где это можно использовать ещё. Хотя нет, могу: скомбинированные с предыдущей аналитикой позволят строить отчёты по определённому типу задач с использованием значений свойств этих задач. Как-то так. 5. Прикрепление задач к объекту (к инфоблокам, например). Загрузили документ. Прикрепили к нему задачу - такой-то посмотри, что-то поправь, вынеси вердикт. Следующий создаёт подзадачу ещё кому-то. Простейший документооборот на задачах. В дальнейшем возможность при просмотре объекта посмотреть связанные задачи (деревья задач). По идее, пп.3,5 - частные, "узаконенные" в системе с соответствующими интерфейсными решениями проявления п.4. Ессно передача этих свойств в события тоже нужна для реализации собственного специфического функционала. 6. Замещение сотрудника - редирект задач на указанного в системе заместителя. 7. История (лог задачи). Раньше было сделано на комментариях форума. Нелепо, но хоть что-то было.
спасибо на лайк не намажешь
|
|
|
|
|
|
Пусть комментируют и голосуют за объединяющий инфоблок. Это я про такой вариант:
спасибо на лайк не намажешь
|
|||
|
|
|
Вам нужен LAMP сервер, на котором вы уже развернёте битрикс и сделаете какие-то настройки. Битрикс тут и упоминать ни к чему даже вроде. Вы купили сервер "МСВСФера", в чём заключаются функции сервера? Какой это сервер? Он не может быть "веб-сервером"? Тогда чем может?
спасибо на лайк не намажешь
|
|||
|
|
|