Ограничение на заполнение столбцов

Question

Есть список. Надо поставить ограничение на заполнение столбцов. Например всего столбцов 20. Каждый элемент списка заполняют 2 отдела. Первый отдел создает элемент, но имеет право на заполнение и изменение только столбцов 1-10. Остальные столбцы остаются пустыми. Потом 2й отдел заходит в изменение элемента и заполняет оставшиеся столбцы, то есть 11-20. При этом первый отдел не имеет право редактировать столбцы 11-20, а 2й - столбцы 1-10. Как такое реализовать?

Answer 1

Есть сторонние решения, которые позволяют скрывать столбцы в зависимости от прав пользователя

Answer 2

Столбцы скрывать не надо. Наоборот, они должны быть видны всем. Необходимо ограничить доступ именно на заполнение.

Answer 3

Пишите свой EventReceiver и в ItemUpdating следите, что юзер изменяет. Если не по чину - линейкой по пальцам...

Answer 4

Из коробки SharePoint не предоставляет ни какой настройки безосности на уровне филдов, поэтому в случае использования одного списка для обеспечения безопасности необходимо следовать советам DkmS, однако на практике чаще просто кастомизируют форму для ввода данных, скрывая или измения состояние контроллов, выводящих значения полей.

 

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

---

SharePoint MCPD, MCITP. Высказанное мною здесь - мои личные взгляды, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий.

Answer 5

А еще можно использовать вот это. Очень Рекомендую ! (Ну или 'кастомаизить' это решение, как пришлось делать мне :) )

UPD: Вы можете использовать InfoPath для настройки логики представления полей на формах.

UPD2: А еще если у вас SharePoint 2010, и ваша логика укладывается в List / Column Validation то можно использовать и этот функционал: слеве List Validation, справа Column Validation:

---

Think -> Search -> Ask -> Think again.

Answer 6

Где-то там же, на codeplex, было китайское решение - у них не только скрывались поля (чего ТСу и не нужно), а показывались в режиме для чтения.

Но в любом случае это неполное решение - никаких разграничений на доступ там нет: пытливый юзер найдёт способ изменить поля, которых ему не видно. А вот обработчика событий обмануть намного сложнее...

Answer 7

То решение( из предыдущего поста) и можно настроить чтобы поле на форме было ReadOnly вроде. (ну в том во что это мутировало в моей компании точно можно :)

Ну "пытливый юзер" в жизни встречается также часто как и "Сферический Конь" + поля скрываются итератором - так что привет пытливому юзеру пытаться способ  найти поля в форме. Edit In Datasheet View ? Ну так настраивайте представления списка соответственно.

А в случае обработчика событий, то я считаю он не подходит для бизнес сценарием по следующим критериям:

1) При необходимости "настроить" или изменить настройки отображения поля необходимо Обязательное присутствие полноценного разработчика SharePoint как минимум.

2) Код который пишется имеет такую неприятную особенность как "бажить"

3) Для того чтобы Написать/изменить логику, оттестировать, установить новое решение нужно в разы больше времени.

4) Человек (не разработчик) с правами Disigner банально не сможет изменить логику а если в компании 7000 человек то такая возможность должна быть предусмотрена иначе будет как-то "дороговато стоить" шарепоинт. (дроговато нанимать доп. разработчика, чтобы при повышении нагрузки он возможно понадобился чтобы скрыть новуб колоночку) - но это особая тема для обсуждения она не относится к вопросу топикстартера.

5) Бизнес-сценарии имеют привычку меняться часто и результат нужно сделать изменения как можно быстрее.

   Т.к. изначально не оговаривалось про версию шарика - то вот пример для 2007-й версии очень подойдет:

    Система должна быть доступна 24/7, когда деплоить? В maintenance time, который 1 раз в неделю в идеале? Или тихо под столом после 18-00 запустить StsAdm -o UpgradeSolution с аттрибутом: -Ну_Я_Щас_Быстренько_Задеплоюсь_Никто_Не_Заметит_даже. И в этот же самый момент в офисе в НьюЙорке компания теряет клиента который не хочет торчать на ресепшене и ждать когдаже "Service Unavailable уйдет клятой" .

6) Как интересно вы EventReceriver'ом скроете ненужные поля на формах создания, просмотра, редактирования ?

А Точно, можно же переделать проект и добавить кучу своих форм для нужных целей, или тем паче написать кучу веб-частей и скрывать их аудиториями :)  (причем у нас изначально ничего про использование InfoPath не говорилось - кстати это еще один вариант, обновлю пост оригинальный).

Примеры абстрактны но весьма реальны. Я в них котел описать суть проблем которые могут возникнуть. Если есть желание я могу описать довольно много причин "провала" для каждого конкретного случая но только не на форуме. - это если захочется поддержать дискуссию можно отдельно встретиться или пересечься где-нибудь на RusUG например.

А так я согласен можно использовать как InfoPath, Thritd-Party tools, EventReceiver. Выбор инструмента должен зависить от задачи которую нужно выполнить и доугих производственных условий. И выбирать инструмент надо не по результатам кто первым ответит на формуе, а по тому.... что скажет Консультант\Архитектор :))))

 

---

Think -> Search -> Ask -> Think again.

Answer 8

Нда... 

Без комментариев...