Есть ещё вариант решения - кастомизировать действие, чтобы оно умело возвращать TaskId. Но тогже не ахти, так как потом это действие придётся обновлять и синхронизировать со штатным ручками.
спасибо на лайк не намажешь
31.01.2013 23:21:04
Ну я вот вообще не понимаю, зачем удалять юзера с КП =) Деактивировал и ладушки. А данные - пусть висят. Может он какое-то знание на КП после себя оставил полезное. Документ, в котором описывал хитромудрогениальный метод решения проблемы, который может пригодится в дальнейшем. Да или контакты сотрудника и тому подобное. А вдруг вернётся вообще?
Ну если сотрудники настолько бесполезные - то...
спасибо на лайк не намажешь
|
|
|
31.01.2013 23:06:54
Ну а что делать. Не было контроля ссылочной целостности, нет и вроде не собирается.
А кроме того - как вы автоматически предлагаете удалять сущности, созданные пользователем? Создал он тему на форуме, где куча людей отписалось, пост блога с такой же историей - куда девать комментарии, фигачить нераздумывая? А элементов ИБ насоздавал, на которые в дальнейшем все ссылаются, что делать?
спасибо на лайк не намажешь
|
|
|
31.01.2013 23:03:57
оригинальное решение =) это и есть извращённые вещи =) к сожалению, требующие необходимости вникать в код модуля БП. впрочем, кастомизация компонентов - тоже и более затратно. Минус - если у вас где-то в параллели было ещё запущено задание на этого пользователя ранее - то получите ид его, а не только что созданного задания. рутактивити тут не нужно. можно попробовать так: $BP = this->GetWorkflowInstanceId(); $ar = CBPDocument::GetUserTasksForWorkflow(1, $BP); $taskID = $ar[0][ID]; UserID - какого юзера нужен айдишник?
спасибо на лайк не намажешь
|
|||
|
31.01.2013 21:49:34
не совсем понятна задача.
как вариант - сохранять при старте время изменения документа в переменную, потом делать паузу на нужный срок, после выхода из паузы проверять, изменилось ли время изменения документа относительно сохранённого в переменной, если нет - выплёвывать ругательство пользователю
спасибо на лайк не намажешь
|
|
|