30 октября 2011 в 6:07
частный случай
Поля могут зависеть от других полей, то есть возможно различное развитие сценария. Например в поле А выбрано значение 1 тогда поле Б = 1,2 или 3, а если А=2 то Б=3,4 или 5
Доступ к полям разных ролей пользователей. Например Кастомер может заполнять поля А,Б,В просматривать Г,Д,Е, менеджер может только редактировать Г,Д, остальные не видит
CCK - позволяет добавлять поля, но они фиксированы и не связанны с другими полями, поле Title не настраивается (то есть оно обязательно) тоже не очень гуд
Какие идеи есть, можно ли решить такую задачу какими нибудь модулями? может кто то уже сталкивался с такой задачей?
решение установка модуля Maestro http://drupal.org/project/maestro
легко связывать любые бизнес процессы
видео 1 http://www.youtube.com/watch?v=1N_2WK6JPXM
видео 2 http://www.youtube.com/watch?v=W8Cg5iBTCC4
видео 3 http://www.youtube.com/watch?v=4DkyEYdFcSY
идеально подойдет для решения задач техподдержки, регистрация тикета, распределение по сотрудникам, решение, проверка... (там даже уже готовый темплайт есть)
вообще любые flow любого ветвления
предлагаю тут выкладывать мысли по поводу решений на базе этого модуля
делиться ньюансами, задавать вопросы.
1 для инициации процесса необходимо выполнить код вида
$newprocess_id = $maestro->engine()->newProcess($template_id);
где его прописать?
Комментарии
такое чувство что это прообраз кнопки "заебись"
что именно?
два раза запостил, как комент потереть?
сам и отвечу
создать ноду или blok (лучше сначала на ноде оттестировать, если будет баг в коде то прийдется доставать бубен и читать тут http://drupalcookbook.ru/recept/otkljuchit-blok), модуль PHP должен быть активирован
<?php
$template_id=1;//номер темплейта
$maestro = Maestro::createMaestroObject(1);
$newprocess_id = $maestro->engine()->newProcess($template_id);
?>
тут вообще живые то есть?
нету, да и вообще сегодня воскресенье.
вот это новость
чего ж раньше молчал... 
он ждал когда твой крик донесется до того склепа, в котором спали)
а если по русски, чего такого суперного сей модуль творит?
визуализированый бизнес процесс реализует, то есть строишь граф и он по нему идет, поддерживается ветвление, условия, параллельность процессов.
только у меня почему то глюк какой то, со стандартным типом ноды артикле работает, а с Basic page или новой созданной нет. Получается стартуешь Start New Process: потом создаешь материал (ноде), а он просто постится и не привязывается к процессу, целый день вчера убил, подозреваю что есть какая то несовместимость с модулями, может кто по тестить?
Не могу понять какой точно ему набор модулей нужен CCK и User Reference так они вроде в 7 называются Fields и Reference
что то никто не просыпается.
были глюки переставил модуль, теперь все нормально работает, нормально работает со встроенным CCK и User Reference
Может ты первый кто у нас заюзал сей модуль? )))
не может быть, ты намекаешь что мне писать туториал?
Ага)) причем намекаю самым наглым образом))
К примеру я понял что модуль жутко наворочен, но так и не одуплился какие задачи он может решать. Видео мне в этом мало помогло, ибо в английском я как бабуин в колхозе.
Вот и интересно, что за зверь, и как его мона попользовать))
Кстати, русификация на него есть?
мою задачу читал? можно реализовать, так же можно практически любой алгоритм прохождения документа реализовать. Напишу свою структуру выложу.
Пока только это http://cotranslate.net/translations/texts/58, участвуйте)))
спасибо за приглашение, но я вам там наперевожуууу )))
А нагрузка? Насколько сильно сие чудо грузит хост?
я только настраиваю, поэтому нагрузочное тестирование не проводилось еще
ну поглядем))) А то хостеры часто от пары тройки вьюх воют)) чтож будет с этим чудом? )))
Вообще нагрузка на проект серьезная предполагается?
Ух, наконец вроде нашел модуль который искал. Пока не тестировал, так что извините за юзерство в отношение модуля. Я правильно понял что он позволяет создать бизнес процесс. А один бизнес процесс может подразумевать создание разных нод с разным уровнем доступа. Например один человек продал и формирует заказ, после создания заказа он доступен складской службе, для отгрузки. На основании которой они могут создавать ноду которая отправляется поставщику. Другими словами у них нет права редактирования ноды заказа, но они её видят, и процесс дальше не пойдёт пока они не создадут ноду для поставщика... дальше процесс идёт с этой нодой.
Я правильно понял что во время бизнес процесса можно использовать разные ноды?
И ещё вопрос можно ли инициализировать во время бизнес процесса другой процесс. Другими словами расписать все и собрать в один?
Сильно ли грузит сайт модуль? У кого сколько сотрудников?
У меня стоит задача отразить бизнес процесс в какой нить системе. Drupal+Maestro вроде как идеальный вариант, но отсутствие документации сильно тормозит дело. После каждого изменения приходится проходить весь граф в поисках отличий.
Вопрос к тем кто пилил что-нибудь на этом модуле.
Я сделал CRM-систему на дру (OG, Flag, Views, webform, workflow).
Как оказалось OG это порождение упоротого мексиканса и токийской шл***, не менее. Постоянные траблы с доступом, полями и кипящим мозгом.
Да и workflow оказалась глючноватая и сыроватая.
Смысл ЦРМки - ведение заказов, документации и задач с множеством типов юзеров.
Лучше на Маэстро такое пилить? Много в ней глюков?
Мы пилим понемногу. Однако к базовым возможностям Маэстро пришлось добавлять дополнительные настройки и писать свой код. Особых глюков у Маэстро замечено не было, кроме разве что недореализованной функции напоминания (Remind) в тасках.
По поводу множества типов юзеров.
Речь, наверное, о разделении пользователей на некие группы с различным набором прав к нодам/термам/views? Если да, то мы такое реализовали с помощью таксономий. Т.е.:
- Есть таксономия представляющая собой перечень рабочих мест, у каждого рабочего места есть настройка доступа к картотекам документов и к полям конкретного типа контента (поле типа "Field Collection", а в нём "Term reference" на таксономию с картотеками и набор чекбоксов, олицетворяющих уровень доступа к соответствующей картотеке, и ещё одно поле типа "Field Collection", а в нём свой тип поля "Field reference" и набор чекбоксов, олицетворяющих уровень доступа к соответствующему полю соответствующего типа контента).
- Дерево картотек документов - это тоже таксономия. Каждая картотека имеет связь с неким типом контента (свой тип поля "Content type reference") - для вывода только документов, принадлежащих данной картотеке.
- У каждого юзера есть поле "Рабочее место", которое по сути Term reference на таксономию "Рабочие места".
- Дерево картотек выводится в обычном блоке, при его построении выполняется проверка принадлежности текущего юзера к некому рабочему месту, а у того рабочего места считываются настройки прав для картотек документов - в результате из дерева картотек изымаются те, к которым у данного юзера нет доступа.
- Переходит юзер на картотеку и видит справа вывод View, который строит закладки а-ля: "Перечень документов", "Создать документ", "Печать перечня документов" и т.д. Если юзер, например, не имеет права на создание документов в данной картотеке (не стоит соответствующая галочка в настройках его рабочего места для данной картотеки), то закладка "Создать документ" не отображается (соответствующий PHP-код вписан прямо в этот View).
- Переходит юзер в некий документ (ноду) текущей картотеки и проверяются настройки прав на поля данного типа контента: если не стоит галочка "Редактирование" для некого поля, то это поле рендерится за-disable-ным (readonly: readonly, disabled: disabled + свой стиль, подкрашивающий поле в серый оттенок для наглядности). Если нет у данного поля даже галочки "Просмотр", то это поле вообще изымается из ноды (кроме, конечно, обязательных полей для заполнения, иначе ж Drupal не даст сохранить изменения в ноде).
Ну, а далее настроен Rule, в котором по созданию ноды запускается некий сценарий Маестро и к этому запущенному сценарию пристыковывается созданная нода. Сценарий либо выбирается в соответствующем поле в самой ноде (свой тип поля "Maestro template reference") либо задаётся жёстко для данного типа контента.
Засчёт возможности настройки прав на каждое поле в любом типе контента мы добиваемся того, что мы можем для каждого участника каждого конкретного сценария скрывать либо ограничивать для редактирования соответствующие поля соответствующего типа контента, экземпляр которого по сути движется по данному сценарию. Это, кстати, как раз то, о чём спрашивал автор топика:
«Доступ к полям разных ролей пользователей.»
Единственное, с чем пока не знаем как лучше справиться - это то, о чём также говорил автор топика: «Поля могут зависеть от других полей, то есть возможно различное развитие сценария. Например в поле А выбрано значение 1, тогда поле Б = 1,2 или 3, а если А=2 то Б=3,4 или 5». Встречали типы полей типа Calculated, но это всё-таки немного не то.
Т.е., в итоге, мы используем такую связку: Maestro + Rules + Views, не считая, конечно, нескольких модулей, реализующих специфические типы полей, и нашего доп. кода.
Вполне вероятно, что некоторые вещи можно было бы решить совершенно иначе и гораздо оптимальнее, но это пока пилотный проект и он пока в глубокой разработке, т.к. возможности, которые даёт модуль Маэстро, в данном проекте - это примерно 40% от всей функциональности. Так что, возможно, кое-что ещё будет рефакториться и не раз.