Вопрос к разработчикам: моё понимание "Администратор" - управление доступом к системе пользователям.
Прекрасно понимаю, что толковый администратор сможет и сам себе роль назначить и увидеть. Но зачем по умолчанию давать доступ на все?
Мало того, я видел реализацию, где Администратор не мог менять себе сам Роли\доступы, а мог делать это только другому администратору.
В нашей системе принадлежность к роли"Администратор" не дает права на просмотр проектов. Такое право дает принадлежность к роли "Руководители".
Однако, Администратор, видит все те проекты, куда его пригласили в качестве участника, исполнительного менеджера, спонсора или заинтересованного лица.
Boiler: Вопрос к разработчикам: моё понимание "Администратор" - управление доступом к системе пользователям. Прекрасно понимаю, что толковый администратор сможет и сам себе роль назначить и увидеть. Но зачем по умолчанию давать доступ на все? Мало того, я видел реализацию, где Администратор не мог менять себе сам Роли\доступы, а мог делать это только другому администратору.
Вот схема Security, используемая в IBN 4.5. Из неё видно, что роль Администратор не даёт право на просмотр (Read) проектов.
· Project
o Create
§ Power Project Manager (global secure role)
§ Project Manager (global secure role)
o Update
§ Manager of the Project
o Delete
o Read
§ Executive Manager (global secure role)
§ Executive Manager of the Project
§ Sponsor of the Project
§ Stakeholder of the Project
§ TeamMember of the Project
o View Finances
o Edit Finances
· Calendar Entry
§ Any user
§ Manager of the Calendar Entry
§ Manager of the Project (if Calendar Entry belongs to Project)
§ Resource of the Calendar Entry
§ Executive Manager of the Project (if Calendar Entry belongs to Project)
§ Sponsor of the Project (if Calendar Entry belongs to Project)
§ Stakeholder of the Project (if Calendar Entry belongs to Project)
§ TeamMember of the Project (if Calendar Entry belongs to Project)
o Finances (only if Calendar Entry belongs to Project)
· Document
§ Any user (if Document doesn’t belong to Project)
§ Manager of the Project (if Document belongs to Project)
§ Manager of the Document
§ Resource of the Document (who is marked as Manager)
o Update Status
§ Resource of the Document
o Add new Version (in Active or Overdue state)
§ Executive Manager of the Project (if Document belongs to Project)
§ Sponsor of the Project (if Document belongs to Project)
§ Stakeholder of the Project (if Document belongs to Project)
§ TeamMember of the Project (if Document belongs to Project)
o View ToDoList
o Add ToDo
o Delete ToDo
o Modify Resources
o Finances (only if Document belongs to Project)
· Task
§ Manager of the Task
§ Resource of the Task (who is marked as Manager)
o Update configuration info
§ Resource of the Task
o Add ToDo (only for not completed Tasks)
o Modify Resources (for non-Milestones and non-Summary)
o Finances
§ Manager of the Issue
§ Manager of the Project (if Issue belongs to Project)
· ToDo
§ Any user (if ToDo doesn’t belong to Project)
§ Manager of the Project (if ToDo belongs to Project)
§ Manager of the ToDo
§ Manager of the Task (if ToDo belongs to Task)
§ Manager of the Issue (if ToDo belongs to Issue)
§ Manager of the Document (if ToDo belongs to Document)
§ Resource of the ToDo
§ Executive Manager of the Project (if ToDo belongs to Project)
§ Sponsor of the Project (if ToDo belongs to Project)
§ Stakeholder of the Project (if ToDo belongs to Project)
§ TeamMember of the Project (if ToDo belongs to Project)
· Issue
§ Help Desk Manager (global secure role)
§ Creator of the Issue (only in New state)
§ Administartor (global secure role)
§ Controller of the Issue
§ Creator of the Issue
§ Resource of the Issue
§ Responsible of the Issue
§ Executive Manager of the Project (if Issue belongs to Project)
§ Sponsor of the Project (if Issue belongs to Project)
§ Stakeholder of the Project (if Issue belongs to Project)
§ TeamMember of the Project (if Issue belongs to Project)
o View ToDo List
o Add ToDo (in New, Open, ReOpen, OnCheck states)
§ Responsible of the Issue (except the OnCheck state)
§ Controller of the Issue (only in OnCheck state)
o Delete ToDo (in New, Open, ReOpen, OnCheck states)
o Assign Responsible
o Finances (only if Issue belongs to Project)
Спасибо, этой схемы не хватало.
Правильно ли я её понял, что реализовать разграничение прав для иерархической структуры более одного уровня не получится, например :
Генеральный директор
Руководитель департамента N
Начальник отдела A департамента N
Менеджер проектов
Менеджер проектовИсполнитель
Исполнитель
Начальник отдела B департамента N
Менеджер проектов1
....
Руководитель департамента X Начальник отдела C департамента X Менеджер проектов Менеджер проектов Исполнитель .................
Руководитель департамента X
Начальник отдела C департамента X
Менеджер проектов Исполнитель
.................
Чтоб Начальник Отдела А видел ВСЕ проекты своего подразделения, но не видел проекты других департаментов и отделов, так же и руководитель департамента - видел ТОЛЬКО проекты своего департамента (за исключением, где его явно вписали в проект).
Хотя сгруппировать пользователей в такую иерархию можно, но исключительно для красоты. поправьте меня, если я ошибаюсь
+1
Кстати да!
У нас та-же проблема! очень нужная функциональность.. а ее нет :(
Преходится всем манагерам давать права проджект манагера, и ничего более, и добавлять их в проекты их отделов как заинтересованных лиц,...
изврат. т.к. если забыл это сделать то руководитель ничего не видит.
К сожалению, в IBN 4.5 сделать описанную иерархическую структуру с разграничением прав нельзя.
Мы активно работаем над тем, чтобы подобное было возможно в IBN 5.0.
Добрый день.
Скажите, а идея сделать иерархическую структуру с разграничением прав утеряна? Или все же работа в данном направлении ведется?
p/s/ Мы собираемся внедрять IBN, но при нашей структуре без этой доработки будет сложновато :( может есть оптимистичные прогнозы :)
Управление проектами Help Desk Service Desk Sharepoint Учет рабочего времени Управление задачами CRM системы и внедрение