Групповой сюрприз
Потребовалось ограничить доступ к списку. Всё, вроде бы, просто – разрешения списка –> прекратить наследование –> удалить разрешения для ненужных групп и пользователей. Но это же Шарепойнт – пропадает ссылка на список в левой панели быстрого запуска. Будь ты хоть кто, с какими угодно разрешениями – хоть бы админ сайта и изготовитель этого списка… 
Исследования показывают, что такой эффект даёт изменение разрешений для встроенной группы “участники узла” – их нельзя удалять, можно уменьшить до “Только просмотр”.
Ну, спасибо… 
Сюрприз от DocumentSet – 3
Вполне возможно, что этот сюрприз и не только к набору документов относится, но нашёл я его именно здесь. Проявляется сюрприз в виде разных наборов “заметок” в веб-части “Доска заметок”, установленной на странице набора документов, в зависимости от активности на сайте фичи “Инфраструктура публикации SharePoint Server”.
Если посмотреть на “своём сайте” список заметок, то там они имеются все, при рассматривании ссылок на объекты комментирования видно, что в УРЛ при неактивной фиче вставлен лишний слеш после имени сервера. Вот и вся причина сюрприза…
Если эксперименты продолжить и формировать заметки не через веб-часть, а через кнопку вверху справа, то сюрприз не наблюдается… Получается, это веб-часть так шутит… Ура индийским братьям!
Не всё так просто…
Потребовалось сделать переустановку Sharepoint Server 2010 – требовалось заменить дистрибутив на Server 2010 for Internet Sites и поменять язык с английского на русский. Казалось бы, пустяковая операция – один дистрибутив снести, другой поставить. Ага, так бы, может, и было два года назад, когда система только вышла, но сейчас навыпущено много изменений и согласовать их между собой – та ещё задача.
На заменяемой системе был установлен sp1 и декабрьский (2011 г.) CU, к моменту переустановки уже был выпущен февральский (2012 г.) CU, и было бы глупым возвращаться к декабрьскому пакету. После установки дистрибутива “Server 2010 for Internet Sites”, сервиспака (вместе с английским языковым пакетом), февральского пакета обновлений и подключения к существующей Sharepoint-ферме оказалось, что “Центр администрирования” формируется с английским интерфейсом, а базы данных не обновляются “Мастером настройки”. С обновлением баз с данными (WSS_Content…) справиться удалось при помощи PowerShell, а вот базы разных служб (особенно упорствовали базы службы поиска) поддались не все. И оставить их в состоянии “как есть” было нельзя – из-за них не выполняется бекап фермы. Вопрос с этими базами “решился” просто – пересозданием служб вместе с базами. А у кого там какие-то данные есть, им как быть?
В итоге в системном логе остались два сообщения об ошибках (одно из них даже Critical):
- Исключение при обновлении адресов для подключенного приложения {e65aeea2-865c-49d8-a394-2ecdeb613811_4c8b4429-9205-4f6f-b3fb-0b4cd99de394}.
- Сбой при попытке синхронизировать веб-приложение 55e17656-0ee7-45ba-87ab-e971ab00ed24; база данных содержимого 23812d7b-3a7c-476c-bf6a-07c1bfec026f
Сообщения эти представлялись совершенно загадочными и никаких сбоев в работе фермы при этом не наблюдалось, а английский интерфейс не менялся при пересоздании “Центра управления” при помощи “Мастера”. Осталось последнее средство – пересоздание фермы. В новой ферме добавил веб-приложение, к которому присоединил базу данных контента – всё стало с нужным интерфейсом, все узлы/подузлы/списки/библиотеки оказались на месте.
Нда… 
Сюрпризик от локализации.
Делал программку генерации списков на узле Sharepoint 2010. В предыдущем проекте такие же действия (создание списка, добавление нужных полей, присвоение русских значений title’ов и т.п.) делал при активации features на узле. Теперь же удобнее было выполнять подобные действия в консольной утилите. Собственно, всё и выполняется без всяких изменений в коде, однако результат получается совсем неожиданным: при просмотре перечня списков в браузере (“весь контент сайта”) видны английские названия, с которыми они создавались методом web.Lists.Add(<EngName>,…), а при просмотре через объектную модель, напр., при помощи PowerShell, видны русские названия, которые присваивались через свойство newList.Title = <RuTitle>; Такая же ситуация с полями списков.
Загадка разрешилась просто – ОС, в которой запускалась утилита – английская, а локализация сайта, на котором генерились списки – русская. Для согласования локалей достаточно в начале программки выполнить присваивание Thread.CurrentThread.CurrentUICulture = web.UICulture;
Собственно, к вопросу о пользе чтения документации. 
Оказывается – 9
Выяснилось, к удивлению и сожалению, что методы класса SPWeb
public override SPBasePermissions GetUserEffectivePermissions(
string userName
)
и
public bool DoesUserHavePermissions(
string login,
SPBasePermissions permissionMask
)
совершенно не учитывают разрешений, получаемых пользователем через членство в группах AD, которым назначены разрешения на узле.
Функция “Проверить разрешения” на странице /_layouts/user.aspx таких разрешений не учитывает тоже. 
SPQuery и ContentType
При работе со списками Шарепойнт обычной практикой, надеюсь, является использование CAML-запросов (свойство SPQuery.Query), которые заметно ускоряют получение данных. Другой возможностью уменьшить объём перерабатываемых данных является ограничение на перечень полей данных (свойства SPQuery.ViewFields и SPQuery.ViewFieldsOnly). Правильное использование помянутых свойств способно заметно улучшить характеристики по быстродействию и потреблению ресурсов.
Проблемы могут возникнуть при попытке использовать характеристики типов содержимого (ContenttType) в списках с поддержкой разных типов. При “чрезмерном” ограничении перечня полей списка можно получить в свойстве SPListitem.ContentType значение null, а в свойстве SPListitem.ContentTypeId совершенно “левое” значение… Для предотвращения подобных проблем следует к списку запрашиваемых полей добавить поле с внутренним именем “ContentTypeId”. При обработке результатов запроса тип содержимого элемента item можно определить кодом наподобие item.ParentList.ContentTypes[item.ContentTypeId].
Оказывается – 8
Нечаянно выяснилось, что определения свойства веб-части в виде
отличаются радикально: первый определяет свойство только для чтения, второй вызывает вывод сообщения о неправильном формате свойства и невозможности десериализации свойств веб-части. 
И никакой отладчик не позволяет найти причину сообщения 
XSLT-сюрприз
Описание – здесь.
В связи с участившимися покушениями на ГДН перенесу текст сюда:
Непонятное наблюдается при отображении дат через настроенную XsltListViewWebPart
Дата 01.02.2010 16:26, т.е. 1-е февраля 2010г., отображается почему-то как 2 января 2010 г.
при этом дата 24.11.2009 10:24 – отображается правильно 24 ноября 2009 г.вот код:
<xsl:value-of select="ddwrt:FormatDate(string($created) ,1049 ,1)" /> |
<xsl:value-of select="$created" /> |
<xsl:value-of select="ddwrt:FormatDate(string($created) ,1049 , 3)" />
вот, что на выходе:
02.01.2010 | 01.02.2010 16:26 | 2 января 2010 г.
24.11.2009 | 24.11.2009 10:24 | 24 ноября 2009 г.Портал русский, поле – системное Created, в БД хранится в поле tp_Created:
2010-02-01 13:26:24.000
2009-11-24 07:24:12.000ошибка связана с реализацией XSLT DateFormat функции в Sharepoint 2010. Чтобы исправить данный bug придется написать свой xsl template, см. ниже:
Снова сюрприз. Многострочный.
При наличии в списке многострочных полей их отображение в стандартных веб-частях зависит от установленного вида этого поля в момент образования элемента списка. В поля списка (“Название” – однострочное текстовое поле, “mlfield” – многострочное) введены одинаковые строковые значения), первые два элемента списка формировались, когда тип поля “mlfield” был установлен в “Обычный текст” и “Форматированный текст” соответственно, третий – “Расширенный форматированный текст”.
Видно, что содержимое “многострочного” поля отображается с вертикальным смещением. (На стандартных списках “Извещения” эффект наблюдается “от рождения”, необходимо только настроить представление на вывод поля “Основной текст”)
В то же время подобного фокуса не наблюдается в “старом” интерфейсе, остающемся после конвертации узлов из версии 2007:
Оставьте комментарий