1. Хранить данные в свойствах профиля, связанных с наборами тегов в службе метаданных. Хронологию изменений вести в новостной ленте.
1.1. Новостная лента (SocialFeedManager) хранит изменения полей профиля (автоматически как 2010), либо есть возможность программно публиковать/доставать записи в ленте через Microsoft.SharePoint.Client.Social/Microsoft.Office.Server.Social или rest, использовать хештеги для разных активностей. Хранится Дата, Пользователь, Текст. Типы фидов SocialFeedType.Personal, SocialFeedType.News, SocialFeedType.Timeline http://msdn.microsoft.com/en-us/library/office/jj163977.aspx#bkmk_GetFeeds http://joxi.ru/m3IcUtg5CbCLaE6lmPk - после синхронизации с АД появились сообщения http://joxi.ru/w3IcUtg5CbDKZ-EXhqQ - сообщения видят фолловеры заполнены автоматически связанные хранилища тегов - http://joxi.ru/jHQcUtg5CbATaM6K5XU
1.2. Список стандартных свойств профиля которые можно использовать Интересы (SPS-Interests), Прошлые проекты (SPS-PastProjects), Спроси меня (SPS-Responsibility), Навыки (SPS-Skills), Дата приема на работу(SPS-HireDate), Должность (SPS-JobTitle)
1.3. Ввод данных в профиль возможен из серверной объектной модели http://msdn.microsoft.com/en-us/library/jj163142.aspx
1.4. Интеграция профиля с поиском. В раздел рефайнеров можно вывести свойство профиля. http://joxi.ru/gS4cUtg5CbCyP1gzT_k или использовать REST http://host/site/_api/search/query? querytext='sharepoint'&refiners='filetype'&refinementfilters='filetype:equals("pptx")' ,
1.5. Через BCS можно связать профили и внешние данные
1.6. Метаданные (теги) - обеспечит целостность справочников, к каждому тегу можно прикрепить метаданные, организовать иерархию, настроить доступ, уведомления об изменении набора, политику добавления новых тегов. Если свойство связано с AD, то набор тегов заполнится автоматически после синхронизации всеми значениями из AD
2. отзывы по аттестации
2.1. Включить в раздел 'Ключевые события' как отдельный тип события
3. Интересы
3.1. Использовать свойства профиля, которое содержит теги интересов
4. Результат (ключевые события)
4.1. Менеджер
4.1.1. Добавить событие указанного типа. При добавлении происходит проверка прав исходя из типа события и CurrentUser.
4.1.2. Получить список ключевых событий выбранного пользователя. возвращает список только тех ключевых событий, которые может видеть currentUser
5. Ключевые события
5.1. Открытые вопросы
5.1.1. Кто может добавлять события???
5.1.1.1. Вариант: сам пользователь и его менеджер.
5.1.1.2. Вариант: только пользователь
5.1.1.3. Вариант: пользователь, его менеджер, бухгалтерия, отдел кадров и все это настраивается
5.1.1.3.1. Поляков: идеальный вариант
5.1.2. Нужно ли разграничение прав доступа по типам событий??? Например, событие 'индексация зп' может создавать только бухгалтерия
5.1.2.1. Поляков: идеальный вариант
5.2. Хранить в списке. Поля: дата события, пользователь.
5.2.1. Вариант 1: Использовать разные контент типы.
5.2.1.1. Если нужно добавить новый тип события, то для этого нужно создать контент тип и добавить его в список событий
5.2.2. Вариант 2: Хранить содержимое в текстовом поле, в виде JSON
5.2.2.1. Небходим дополнительный список, в котором хранятся типы событий. Список 'Типы событий' хранит параметры события в JSON.
5.2.3. Чтение, добавление, изменение данных списка
5.2.3.1. Использовать стандартные формы SharePoint
5.2.3.1.1. Вопрос разграничения прав доступа.
5.2.3.2. Использовать свои формы
5.2.3.2.1. можно настроить сложную бизнес логику. Например данные может заносить как сам человек, так и его начальник, бухгалтерия и т.д. Конечно, если такая информация имеется
5.3. Разграничене прав доступа
5.3.1. Вариант 1: хранить набор групп пользователей в элементе списка 'типы событий', и при добавлении события проверять пользователя на принадлежность к перечисленным группам.
5.3.2. Вариант 2: Для каждого пользователя заводить отдельную папку, в которой будут храниться события для данного пользователя. События по папкам будут раскидываться при сохранении события (event receiver). При создании новой папки на нее можно навесить права. Например разрешить изменять пользователю и руководству подразделения в котором состоит пользователь
5.3.3. Вариант 3: иерархическая структура папок. Для каждого подразделения создается своя папка (с учетом иерархии). Доступ к папкам руководителям подразделений. В остальном - как в предыдущем варианте. Возникают сложности со сменой должности.
6. Когда пришел, кем работает сейчас
6.1. Использовать свойства профиля, синхронизация с AD
7. Проекты
7.1. Открытые вопросы
7.1.1. Нужна ли иерархия проектов?
7.1.1.1. Поляков: Нет
7.1.2. Нужно ли хранить сроки участия в проекте?
7.1.2.1. Поляков: Да
7.1.3. Нужно ли хранить роль пользователя в проекте?
7.1.3.1. Поляков: Да. И описание работ
7.1.4. Кто должен иметь доступ к изменению?
7.1.4.1. Поляков: Пользователь и вышестоящие
7.2. Список проектов. Поля: название, сроки, тип проекта, описание проекта
7.2.1. Поляков: пример
7.3. Список пользователей участвующих в проекте. Поля: дата начала, дата окончания, роль, обязанности
7.3.1. +Описание
7.3.2. Поляков: пример
7.3.3. Заменить на события
7.4. Будет в виде узла, на котором расположена библиотека проектов
7.4.1. Вся информация о проекте хранится в контент-типе
7.4.2. У библиотеки проектов будет ивент-ресивер, который при смене статуса проекта (с пресейла на статус 'в работе') будет создавать подузел проекта