Вопросы Program Central.

[Wireless_Fidelity]

Есть R2013 и установленный на ней Program Central.
В ходе изучения системы возникает множество вопросов и багов, хотелось бы уточнить у присутствующих, есть ли кто-нибудь, кому удавалось эксплуатировать сей чудо-продукт индийского кода?

[Геройчиковый]

я пока что до Р2012х дошёл...Р2013 видел только на картинках... Хотя смею предположить что количество ДжаваСкрипта там уже зашкаливает...
Когда ещё в Р2011х пыталс работать - наткнулся на неприятные баги, связанные с тем, что в РФ формат дат как-то отличалется от того, что ожидает эновия, и когда пытался проставить задания в проекте и их сроки - были ошибки. Даже создавал Service Request для дасошников на эту тему... Но они после месяца разбирательств, сказали, что: извините, Русский пока что не сертифицированный язык для Эновии, по этому мучайтесь сами, если хотитие. Вот вам список JSP и прочих ресурсов где вы можете что-то поменять, чтобы ваши даты распознавались как надо.
Плюс были какие-то мелкие баги, но в целом - перевариваемые.
Ауж что там в Р2013 накрутили.. даже предствить не могу...

[Wireless_Fidelity]

Тут в состав централа входит около 400 jsp. Вот зачем DS выдумывать JPO, триггеры, какие-то стандартные практики кастомизации/программирования, чтобы в собственном же приложении всю бизнес-логику зафигачить в самописные ненастраиваемые jsp? О какой настройке можно говорить, если сервисная, не основная, команда централа использует jsp на 63кб для вызова ровно одного метода из jpo? Это они предлагают нам настраивать?
Даже я, энтузиаст Enovia, начинаю считать, что весь потенциал кастомизации убивается убогой реализацией приложения. Мне кажется, Дасо всерьез следует отказаться от центров разработки в Индии и их ускоренного цикла обновлений приложений. Им следует в первую очередь заплатки клепать и дорабатывать функционал, а не создавать новые приложения.
Заколебало исправлять их код...

[Fil]

Добрый день!
Имел удовольствие общения с PRG2013.HF2.

[Wireless_Fidelity]

Здравствуйте.
Сразу задам, наверное, наиболее актуальный вопрос. Есть график работ. В нем, понятное дело, крупные позиции разбиты на более мелкие, для каждой из работ установлены сроки начала и конца. При попытке воспроизвести эту структуру в централе выходит, что сроки заданий на нижнем уровне структуры влияют на верхние задания, и каждое добавление подзадания смещает срок работ всему графику. Как сделать сроки заданий более жесткими? Предлагаемый механизм ограничений позволяют влиять только на одну из предельных дат (начало или конец).

Также выглядит дикостью возможность исполнителю задания Отказаться от его исполнения или назначить другого. Удивительная функция.

[Fil]

Можно, пожалуйста, более развернуто описать конкретный пример (как есть и как хочется чтобы было)? Тот факт, что сроки выполнения задачи вычисляется из сроков подзадач весьма логично.

[Wireless_Fidelity]

Безусловно, логично, но только если вносимые исполнителем задания изменения не сдвигают остальные работы по проекту.

Задание-0
Задание-1 с 1 апреля по 1 мая
Задание-2 с 1 мая по 1 июня


Таким образом, срок проекта с 1 апреля по 1 мая, как и было запланировано первоначально.
Разбиваем задание-2 на подзадания:
Задание-2
Задание-2.1 с 1 мая по 20 мая
Задание-2.2 с 20 мая по 10 июня

Срок окончания всего проекта (Задания-0) переехал на 10 июня. Сроки заданий проекта исчисляются со дня его начала, потому как необходимо начать и заканчивать работу во вполне конкретные сроки.
А все постольку, поскольку контроля за назначаемыми срока нет. В данном случае сроки подзадания 2.2 выходят за рамки родительского задания, что, очевидно, недопустимо.

[Fil]

Думаю, что стоит, в первую очередь посмотреть политику Project Task. В части User Public Modify посмотреть, в частности фильтр, и, возможно, вынести TASK_ASSIGNEE в отдельный контроль, чтобы необходимым образом убрать доступ к изменениям Task-ов в целом.

Насколько я понял, необходимо, чтобы Task Assignee не мог в результате своих действий, каким-либо образом поменять атрибуты объекты типов Task Management в которых он не является Onwer-ом. Для этой задачи можно Rules прописать, которые будут контролировать доступ к конкретным атрибутам (т.к. практически любое изменение сделанное в подзадаче отразится на родительской задаче, особенно если речь о сроках, то придется ограничить изменения дат вообще).

Можно поставить modify триггеры на задачу, но в общем случае написать такой триггер может оказаться достаточно сложно, т.к. задачи могут быть связаны сложным образом схемами dependencies и проверку придется выполнять комплексную. Однако, если необходимо "просто" анализировать не увеличится ли срок родительской задачи в результате изменения какого-либо атрибута подзадачи, то триггер будет не сложный.

[Геройчиковый]

Ничего себе у вас тут дискусси
Слава богу моим заказчикам пока что ничего такого в голову не пришло ))

Кстати о Програм Централе: знаете, там вот когда смотрите на WBS, можно вызать апплет который отображает эту диаграмму Ганта? Вот у меня такой вопрос - никто не в курсе - можно ли это чудо как-то настраивать?

[Fil]

Думаю, что инструментов для настройки не предоставляется... только влезать. Кстати, в 2013 её (диаграммы Ганта) теперь ещё и 2 варианта

[Геройчиковый]

Ого, даже так... Надеюсь что скоро это увижу своими глазами....