Сервис для
сео - оптимизаторов

Найди ошибки на сайте
Ошибки мешают продвижению сайта
Исправь ошибки на сайте
Сайт без ошибок продвигать легче
Получи новых клиентов
Новые клиенты принесут больше прибыль

SharePoint 2013 - изменение порядка свойств профиля пользователя

Недавно к нам обратились с просьбой разрешить сотрудникам добавлять собственный текст в подписи к электронной почте. Просто, подумал системный администратор, мы просто поместим его в свойство Active Directory, а затем внесем это в правила, которые создают подписи. Критерий сортировки.

Но как мы можем получить текст там? Будем ли мы получать от службы технической поддержки обновление Active Directory каждый раз, когда кто-то захочет изменить свой текст? Конечно, нет! Нам нужен способ, позволяющий персоналу обновлять это для себя.

Именно здесь приходит SharePoint. Мы создаем новое свойство профиля пользователя, задаем ему подходящие параметры, чтобы люди могли просматривать и обновлять его, а также создаем сопоставление свойств для синхронизации с Active Directory. Работа сделана, время для кофе ....

Но люди недовольны, когда они пытаются изменить свой профиль в SharePoint, они не могут найти текстовое поле для нашего нового свойства. Зачем? Потому что SharePoint решил поместить его в раздел пользовательских свойств !

И какой смысл давать нашим людям новую функциональность, а затем затруднять ее поиск? Спасибо SharePoint!

Итак, давайте перенесем наше новое поле в раздел « Контактная информация », где его будет легче найти и в котором есть разумный смысл. Выключите « Центральный администратор»> «Управление приложениями-службами»> «Служба профилей пользователей»> «Управление свойствами пользователя», где мы находим, что единственный способ переместить свойство - использовать стрелки вверх или вниз в списке:

И SharePoint делает обратную передачу для каждого клика! Нужно ли нам серьезно нажимать на эту стрелку, подождать, пока страница перезагрузится, снова прокрутить до нашего свойства (теперь на целую строку вверх по списку) и щелкать снова и снова, пока оно не окажется в нужном месте? Вау, SharePoint, вы действительно помогли нам на этот раз.

К счастью, так быть не должно. PowerShell помогает в случаях, когда графический интерфейс терпит неудачу, и это так просто:

Шаг 1 - получить текущий порядок отображения свойств нашего профиля пользователя:

$ MySite = Get-SPSite http: // <mysite-url>

$ context = Get-SPServiceContext $ MySite

$ profileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager ($ context)

$ profilemanager.properties | имя, номер заказа

Это выведет список свойств с номером для каждого из них, указывающим порядок отображения. Есть много пробелов в последовательности номеров заказов, поэтому, если вам повезет, вы сможете выбрать неиспользованный номер там, где вы хотите. Мы хотим, чтобы наше пользовательское свойство указывало сразу после свойства «Ассистент» в «Контактной информации», которое, к счастью, будет иметь номер 5110, и мы можем использовать 5111 для нашей собственности, не вызывая никакого конфликта.

Мы хотим, чтобы наше пользовательское свойство указывало сразу после свойства «Ассистент» в «Контактной информации», которое, к счастью, будет иметь номер 5110, и мы можем использовать 5111 для нашей собственности, не вызывая никакого конфликта

Шаг 2 - сообщите SharePoint номер заказа отображения, который мы хотим использовать для нашей собственности:

$ ProfileManager.Properties.SetDisplayOrderByPropertyName ( "EmailSig-AddInfo", 5111)

$ ProfileManager.Properties.CommitDisplayOrder ()

И все, наше новое свойство теперь удобно расположено в контактной информации формы редактирования профиля пользователя, где его можно легко найти, и оно действительно может быть использовано и не забыто.

И все, наше новое свойство теперь удобно расположено в контактной информации формы редактирования профиля пользователя, где его можно легко найти, и оно действительно может быть использовано и не забыто

Похожие

Пользовательский агент или мобильный шаблон
Во многих других реализациях OAuth вы увидите два потока: один для сценариев использования веб-приложений на стороне клиента (Javascript) и второй для сценариев использования мобильных приложений. Например, реализация Google OAuth 2 разделяет User Agent и Mobile на отдельные потоки и помечает их как Клиентское приложение и Установленное приложение. Наша реализация рассматривает их как единый поток. Но отличительной особенностью является то, что клиентское приложение, которому нужно получать
Но как мы можем получить текст там?
Будем ли мы получать от службы технической поддержки обновление Active Directory каждый раз, когда кто-то захочет изменить свой текст?
Зачем?
И какой смысл давать нашим людям новую функциональность, а затем затруднять ее поиск?