Temat: Zmiana praw na podstawie wartości w kolumnie

Witam,

Czy wie ktoś może jak można prosto (a przy okazji ładnie) załatwić poniższy problem?

Potrzebuję, aby prawa do dokumentu (znajdującego się w Documnet Library) zmieniały się w zależności od wartości w kolumnie X.

Niech kolumna ta definiuje na przykład status danego dokumentu (Draft - Waiting for Approval - First Approval - Final Approval itd.). Do każdego statusu przypisana jest inna grupa użytkowników, która to może go edytować tylko gdy osiąga odpowiedni status. Jeżeli dokument osiąga status Final Approved to jest już nieedytowalny (na tym dokumencie wszystkie grupy biorące udział w zabawie dostają prawa read only).

Pisząc o edytowaniu, chodzi mi o edytowanie elementu danej listy, a więc zarówno samego dokumentu jak i jego wartości w kolumnach.

Wiem, że SharePoint ma "Content Approval", ale opcja ta raczej nie wchodzi w grę - użytkownik po aprobacie dalej może edytować item. Wiem również że problem można próbować rozwiązać z poziomu custom Workflow poprzez Designera. Ktoś ma pomysł jak? A może ktoś jeszcze ma inne ciekawe pomysły?

Pozdrawiam,
Sławek

Temat: Zmiana praw na podstawie wartości w kolumnie

Prosto, to chyba można wykorzystać to rozwiązanie:
http://splistdisplaysetting.codeplex.com/

Do ograniczenia uprawnień, a ewentualnie na widoku listy ustawić filtry tak, żeby użytkownicy widzieli elementy wg statusu, do którego mają mieć dostęp.

Przy czym niekoniecznie jest to ładnie ;)

Można napisać też odbiornik zdarzeń do listy, który obsługiwałby event ItemUpdated i tam zmieniał uprawnienia. To byłoby chyba ładniej, ale już nie tak prosto.

Skoro już o eventach mowa - można też obsługiwać ItemUpdating (lub już ItemCheckingOut) i blokować go w zależności od wartości w polach i uprawnień użytkownika. Tutaj trochę trzeba by pokombinować, by zachować elastyczność i nie zaszywać w kodzie reguł.

Temat: Zmiana praw na podstawie wartości w kolumnie

Rozwiązanie z codeplex interesujące - dzięki.

Zabawę z widokami(a raczej oszukiwanie) znam już za dobrze - tak jak piszesz... jest to nieładne :)

Nad eventami właśnie siedzę i chyba faktycznie tak postaram się to rozwiązać.

A wie ktoś może jak sprawa wygląda w SharePoint 2010?

Temat: Zmiana praw na podstawie wartości w kolumnie

Można napisać też odbiornik zdarzeń do listy, który obsługiwałby event ItemUpdated i tam zmieniał uprawnienia. To byłoby chyba ładniej, ale już nie tak prosto.

na ItemUpdated bedzie problem, ze wzgledu na to ze jak zaktualizujesz uprawnienia i zrobisz update to znow Ci wywola event (jezeli masz ich kilka to jestes zalatwiony, jezeli masz tylko jeden to wystarczy DisableEventFiring()). Mozna to obejsc za pomoca SuppressAfterEvents jednak nie wiem czy to nie lamie supportu msowego, tutaj jest opis ja kto mozna zrobic:

http://blog.gutek.pl/post/2009/01/15/Tips-Tricks-10-Wy...

Skoro już o eventach mowa - można też obsługiwać ItemUpdating (lub już ItemCheckingOut) i blokować go w zależności od wartości w polach i uprawnień użytkownika. Tutaj trochę trzeba by pokombinować, by zachować elastyczność i nie zaszywać w kodzie reguł.

Nie, mozna zrobic prosta delegate kontrolke i podpiac ja pod Header i blokowac dostep do elementu za pomoca jej. Jezeli robisz to za pomoca Updating to zezwalasz mu tak naprawde na edycje mimo iz nie powinien miec od niej dostepu. Cos podobnego - blokujacego dostep do danego widoku listy - mozna zobaczyc tutaj:

http://blog.gutek.pl/post/2010/03/17/SharePoint-List-V...

jest tam delegate control ktora w zaleznosci od kontekstu i uprawnien zezwala lub nie zezwala na ogladanie strony.

IMO, uprawnienie w kolumnie nadawane albo z miejsca (przez jakas osobe) albo automatycznie na ItemUpdating (przypisanie uprawnienia na podstawie jakis wartosci) + delegate control powinien zalatwic problem i bedize dzialal dosc sprawnie.

Temat: Zmiana praw na podstawie wartości w kolumnie

Jezeli robisz to za pomoca Updating to zezwalasz mu tak naprawde
na edycje mimo iz nie powinien miec od niej dostepu.

To jest cały czas przy założeniu filtrowania w widokach. Podpięcie pod ItemUpdating i przyblokowanie e.Cancel=true uniemożliwi edycję elementu skutecznie, ale nie jest rozwiązaniem wystarczającym - tylko łatającym lukę w przypadku filtrów widoku.

Co do ItemUpdated - jak najbardziej z użyciem DisableEventFiring();
Po prostu zmiana post factum uprawnień adekwatnie do obecnie ustawionego stanu elementu. Nie wiem, w czym tu przeszkadza ewentualna obecność więcej, niż jednego eventu. Przed ustawieniem uprawnień można po prostu je sprawdzić i jeśli są takie, jak trzeba, to nie robić nic więcej.

Zupełnie inna kwestia, to zasadność używania takiego rozwiązania zamiast przepływu pracy, który jest do tego jak znalazł. Czy nie? ;)Piotr Dudzic edytował(a) ten post dnia 07.05.10 o godzinie 11:35

Temat: Zmiana praw na podstawie wartości w kolumnie

Piotr Dudzic:

Jezeli robisz to za pomoca Updating to zezwalasz mu tak naprawde
na edycje mimo iz nie powinien miec od niej dostepu.

To jest cały czas przy założeniu filtrowania w widokach. Podpięcie pod ItemUpdating i przyblokowanie e.Cancel=true uniemożliwi edycję elementu skutecznie, ale nie jest rozwiązaniem wystarczającym - tylko łatającym lukę w przypadku filtrów widoku.

to jest blokada fiznyczna aktualizacji elementu, przez co użytkownik dowiaduje sie o tym odpowiednio dlugo po fakcie edycji. co wplywa na funkcjonalna czesc aplikacji. Gdybym natrafil na taka to bym poprostu przestal z niej korzystac - po co mi formularz edycji skoro nie moge potem tego zapisac?

Co do ItemUpdated - jak najbardziej z użyciem DisableEventFiring();
Po prostu zmiana post factum uprawnień adekwatnie do obecnie ustawionego stanu elementu. Nie wiem, w czym tu przeszkadza ewentualna obecność więcej, niż jednego eventu. Przed ustawieniem uprawnień można po prostu je sprawdzić i jeśli są takie, jak trzeba, to nie robić nic więcej.

Zupełnie inna kwestia, to zasadność używania takiego rozwiązania zamiast przepływu pracy, który jest do tego jak znalazł. Czy nie? ;)Piotr Dudzic edytował(a) ten post dnia 07.05.10 o godzinie 11:35

nie, przeplyw pracy to jedna z najwiekszych bolaczek SharePointa 2007. Moze po 3 latach patchy w koncu go naprawili ale juz sie 4 krotnie na nim przejechalem i po prostu go przestalem stosowac. Zarowno wydajnosciowo jak i funkcjonalnie WF w SharePoint nie nadaje sie do niczego trudniejszeo niz prosty approval.

Jak masz wiecej niz jeden event asynchroniczny to nie wiesz ktory z nich jest "konieczny" by sie uruchomil i przy jakiej operacji on musi sie uruchomic oraz kiedy on sie uruchomi. CZyli w momencie update na swoim elemencie moze on juz byc przestarzaly - nie masz pewnosci kiedy bedzie a kiedy nie. Na 1000 przypadkow mozesz miec 1-2 takie problemy lub 990. Dzieje sie tak gdyz Allow Event Firing jest sprawdzany tylko raz przed wywolaniem wszystkich eventow podpietych pod dane zdarzenie.

zreszta w nowym SharePoint ustawienie DisableEventFiring wcale nie powoduje iz event sie nie wykona, wszystko zalezy od glebokosci wykonywanego zdarzenia;)

Temat: Zmiana praw na podstawie wartości w kolumnie

Jakub Gutkowski:

Piotr Dudzic:

Jezeli robisz to za pomoca Updating to zezwalasz mu tak naprawde
na edycje mimo iz nie powinien miec od niej dostepu.

To jest cały czas przy założeniu filtrowania w widokach. Podpięcie pod ItemUpdating i przyblokowanie e.Cancel=true uniemożliwi edycję elementu skutecznie, ale nie jest rozwiązaniem wystarczającym - tylko łatającym lukę w przypadku filtrów widoku.

to jest blokada fiznyczna aktualizacji elementu, przez co użytkownik dowiaduje sie o tym odpowiednio dlugo po fakcie edycji. co wplywa na funkcjonalna czesc aplikacji. Gdybym natrafil na taka to bym poprostu przestal z niej korzystac - po co mi formularz edycji skoro nie moge potem tego zapisac?

Po co próbujesz edytować elementy, do których nie masz dostępu przez interfejs? ;)
Tak jak mówiłem - łatka. Nieelegancka, ale skuteczna i prosta. Nie twierdzę, że to rozwiązanie jest dobre. Po prostu uznałem, że spełnia wymagania.

Co do ItemUpdated i workflow

Asynchroniczność - racja. Nie pomyślałem o tym.
Problem pojawiłby się, gdyby eventy odpalały się nie po kolei.
Możliwe, że dałoby się to jakoś sensownie obejść przekazując jakieś dodatkowe metadane do eventu, ale to chyba więcej zachodu i eksperymentowania, niż jest warte.

Co do przepływu pracy - ja takich problemów akurat nie spotkałem. Obiegi potrafią chodzić wolno, a czasami zabawnie po cichu się przewrócić, ale ten myk ze zmianą uprawnień niewiele różni się od prostego approvala.

Temat: Zmiana praw na podstawie wartości w kolumnie

Polecam rozwiązanie:
http://www.webcon.pl/produkty.php?kat=22&kat2=1&kat3=9
Spełnia dokładnie te wymagania. Niestety nie jest darmowe i nie jest tanie. 30 dniowa wersja testowa dostępna pod linkiem powyżej.

Temat: Zmiana praw na podstawie wartości w kolumnie

Szymon Bochniak:
Polecam rozwiązanie:
http://www.webcon.pl/produkty.php?kat=22&kat2=1&kat3=9
Spełnia dokładnie te wymagania. Niestety nie jest darmowe i nie jest tanie. 30 dniowa wersja testowa dostępna pod linkiem powyżej.

szczerze? nie ma sensu, napisanie tego zajmuje tydzien (biorac pod uwage opcje konfiguracyjne, bo samo zabezpieczenie to niecale 2-3h).

Wystarczy tylko troche blogow poczytac i nie dac sie "zwabic" przez dodatkowe funkcje.