none
Ограничение на выбор элементов в списке RRS feed

  • Вопрос

  • Коллеги, добрый день!

    Имеются данные:

    Банк терминов:

    1) Иванов - доверенность 1;

    2) Петров - доверенность 2;

    3) Сидоров - доверенность 3, доверенность 4.

    Списки:

    1) Заместители;

    2) Доверенности.

    В списке Заместители есть поля: Заместитель (метаданные) и Доверенность № (подстановка из списка Доверенности).

    Можно ли средствами SP (без кода), сделать ограничение, чтобы при добавлении элемента в список Заместители в поле Доверенность № отображались только те доверенности, которые прописаны в синонимах у этого Заместителя, а не все элементы по умолчанию.

    К примеру, добавляю элемент в список Заместители:

    в поле Заместитель: Петров

    в поле Доверенность №: можно выбрать только доверенность 2

    3 июля 2014 г. 14:17

Ответы

  • Ну еще предложу вариант такой, возможно придется пересмотреть архитектуру решения, но что не сделать ради конечного результат.

    Если данные берутся из списка подстановки, то делаем так:

    1. Прекращаем наследование прав у списка от родителя.
    2. На каждую запись с номерами доверенностей назначаем уникальные права так, что бы их мог прочитать только владелец доверенности (права на чтение), остальным нет доступа.
    3. Готово.

    Т.к. у других Заместителей не будет прав на чтение чужих элементов, то и в строке подстановки они их не увидят, а будут только свои значения.

    Попробуйте, no code, best way :)

    • Предложено в качестве ответа Maxim Shusharin 4 июля 2014 г. 8:08
    • Отменено предложение в качестве ответа Maxim Shusharin 5 июля 2014 г. 4:48
    • Помечено в качестве ответа Valdemar.Miller 7 июля 2014 г. 13:36

Все ответы

  • Добрый день!

    Думаю, что это возможно сделать средствами форм InfoPath. Если конечно у Вас SharePoint server Enterprise, который поддерживает InfoPath service. Все зависит от того, в каком сценарии Вы хотите делать эти ограничения.

  • Добрый!

    Microsoft SharePoint Foundation 2013 :(

  • Тогда как вариант, попробовать фильтровать значения посредством SharePoint Designer.
  • Да InfoPath был бы выходом... Но Microsoft не будет заниматься развитием настольного клиента InfoPath и служб InfoPath Forms Services в SharePoint Server (их техническая поддержка в соответствии с общей политикой корпорации управлении жизненным циклом продуктов будет поддерживать до 2023 г.).

    Можно использовать jQuery-ui  + SP.Services

    Через SP.Services запрашиваем данные с фильтрацией по Заместителю, а через jQuery-ui делаем поля подстановки. Не совсем без кода, зато без Visual Studio обойдемся.

  • Тогда как вариант, попробовать фильтровать значения посредством SharePoint Designer.
    Не получится. Вы сделаете статический CAML Query, а для данной задачи нужен динамический.
  • По поводу InfoPath конечно же согласен с Вами, но поддержка InfoPath service есть до сих пор и в 2013 версии сервера. С учетом того, что многие пользователи сидят до сих пор на 2007 версии. Поэтому, как выход из данной ситуации без когда, InfoPath подошел бы в качестве альтернативы. Естественно, что jQuery + API SahrePoint самый действенный и перспективный вариант на данный момент, но с программированием.
  • Не получится. Вы сделаете статический CAML Query, а для данной задачи нужен динамический.

    В таком случае, тогда только через программирование.

  • Через SP.Services на newform делается элементарно, если не устраивает такой вариант, предложу другой (принцип тот же, но уже готовое решение): SharePoint Cascaded Lookups

     

    Вообще в сети много информации по этой теме - гул по запросам:

    Filtered lookup column

    cascaded lookup column (fields)

    cascaded drop down lists.


  • Большое спасибо за советы!

    Буду пробовать искать. Если получится, то отпишусь.

  • Ну еще предложу вариант такой, возможно придется пересмотреть архитектуру решения, но что не сделать ради конечного результат.

    Если данные берутся из списка подстановки, то делаем так:

    1. Прекращаем наследование прав у списка от родителя.
    2. На каждую запись с номерами доверенностей назначаем уникальные права так, что бы их мог прочитать только владелец доверенности (права на чтение), остальным нет доступа.
    3. Готово.

    Т.к. у других Заместителей не будет прав на чтение чужих элементов, то и в строке подстановки они их не увидят, а будут только свои значения.

    Попробуйте, no code, best way :)

    • Предложено в качестве ответа Maxim Shusharin 4 июля 2014 г. 8:08
    • Отменено предложение в качестве ответа Maxim Shusharin 5 июля 2014 г. 4:48
    • Помечено в качестве ответа Valdemar.Miller 7 июля 2014 г. 13:36
  • Т.к. у других Заместителей не будет прав на чтение чужих элементов, то и в строке подстановки они их не увидят, а будут только свои значения.

    Интересное решение, надо будет попробовать.
  • Ну еще предложу вариант такой, возможно придется пересмотреть архитектуру решения, но что не сделать ради конечного результат.

    Если данные берутся из списка подстановки, то делаем так:

    1. Прекращаем наследование прав у списка от родителя.
    2. На каждую запись с номерами доверенностей назначаем уникальные права так, что бы их мог прочитать только владелец доверенности (права на чтение), остальным нет доступа.
    3. Готово.

    Т.к. у других Заместителей не будет прав на чтение чужих элементов, то и в строке подстановки они их не увидят, а будут только свои значения.

    Попробуйте, no code, best way :)

    Факт в том, что это будут делать не рядовые пользователи (сами замещаемые), а 1 человек будет назначать заместителей. Так, что ему необходимо видеть все доверенности:)
    4 июля 2014 г. 12:39
  • Факт в том, что это будут делать не рядовые пользователи (сами замещаемые), а 1 человек будет назначать заместителей. Так, что ему необходимо видеть все доверенности:)

    Добрый день, тогда SP.Services, как я уже описал. Если назначать будет один человек, то без кода не обойтись.