Wypowiedzi
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Konrad K.:
Witam,
Z pudełka takiego uniwersalnego szukacza nie kojarzę. Możesz sprobować napisać takiego samograja np. w formie extension do SPWeb, w którym po kolei szukasz po konkretnych kolekcjach w poszukiwaniu elementu z poszukiwanym Guidem.
lojojoj za sama probe napisania czegos takiego :)
tak pozatym widzimy sie w listopadzie? :)
-
To po kolei:
1) Nikt nikomu nie karze przechodzic na kolejne wersje produktow. wciaz mozna pisac aplikacje w Visual Studio .NET 2003 jak i w VS 2005. Tak jak i wciaz sa aplikacje na SPS 2003, tak i wciaz beda powstawac aplikacje na 2007 jak i na 2010. Zeby skorzystac z .NET Framework 4.0 musisz skorzystac z VS 2010. Zeby zainstalowac Viste trzeba bylo wymienic sprzet, zaby z upgradowac Maca trzeba kupic nowego itp itd. ogolnienia. Ale tak to dziala w IT nie zaleznie od opini publicznych.
2) UI to kwestia gustu. Dla Ciebie jest gorzej dla innego bedzie lepiej a dla osoby z biura ktora pracuje na Office 2007 i 2010 i ma wyklikac liste raczej bedzie bedzie odpowiednia, przynajmniej ujednolicona. Dodatkowo nowe UI umozliwia szereg mozliwosci jego rozszerzenia o nowe funkcjonalnosci, co w poprzednich wersjach ograniczalo sie do linkow w QuickLaunch lub Site Action.
3) Stare bledy sa i temu nikt nie zaprzeczy, niestety mimo usilnych prob namowienia ludzi z redmond by jadnak zajeli sie bledami o ktorych wszyscy wiedza, nie ruszyli nawet palcem, choc kilka rzeczy dodali, ktore napewno pomoga developerom w tworzeniu nowych rozwiazan. Co do wartosci biznesowej - ty moze nie, nie wiem czym sie zajmujesz i co robisz na SharePointcie ale pod wzgledem biznesowym jest masa nowych funkcji w tym chociazby polaczenie Performance Point z SharePoint (produktu PErformance Point juz nie ma), Visio Services, PowerPivot, Claim based authentication i tak moglbym wymienic dalej. Wszystko zalezy do czego stosujesz SharePoint, jak do hostowania stronki ASP.NET to nie znajdziesz nic nowego, bo hostowanie wyglada tak samo jak poprzednio. JEzeli jednak korzystasz z funkcji SharePointa dla biznesu znajdziesz szereg noweosci i udogodniej. Jak to sie zachowa w biznesie? pokaze czas. SharePoint 2007 mial swoje problemy i dalej je ma, SharePoint 2010 narazie nie ma ich az tyle ale wcaiz jest to nowy produkt i nie wszystko bylo dokladnie na pewno przetestowane.
-
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.
-
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;)
-
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.
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Tomasz Szymański:
Musisz napisać EventHandlera który podczas dodawania elementu do listy nada odpowiednie uprawnienia per element. Jest to jakieś rozwiązanie... . Informacjie o tym jak się pisze i podczepia EventHandlery jest dużo w necie.
powodzenia
napisalem to juz w odp innej ze lepiej sie w uprwanienia nie bawic. Tutaj moze wyjasnie, chodzi o ograniczenie unique security principals wiec jezeli firma ma 200 uzytkownikow to spoko ale jezeli wiecej to lepiej z uprawnien na elemetnach nie korzystac :)
http://blog.gutek.pl/post/2008/06/24/Usuwanie-uprawnie...
Gutek
http://blog.gutek.pl
http://dotnetblogs.pl
-
Tomasz R.:
Mam taki oto problem i powiem szczerze, nie wiem jak go ugryzc:
1. Mam jedna liste niestandardowa
2. Mam dwa zespoly ludzi, kazdy zespol ma przelozonego
3. Kazda osoba z tego zespolu powinna widziec tylko swoje elementy na powyzszej liscie
4. Kazdy przelozony powinien widziec tylko elementy ludzi ze swojego zespolu. Nie powinien widziec elementow innego zespolu.
Czy cos takiego da sie zrobic w sharepoint? Jesli tak, to jak? :)
odpowiadajac krotko, da sie. odpowiadajac dluzej :) to zalezy jak chcialbys to rozwiazac.
1) Po pierwsze kasujesz "View Selector", mozesz to zrobic edytujac szablony kontrolek, lub przeciazajac go na tyle by dla danej listy sie nie wyswietlal. Inna opcja to poprostu WebPart wyswietlajacy okreslony widok listy (bez mozliwosci podejrzenia innych widokow)
2) Tworzysz widok dla pracownika gdzie utworzony/zmodyfikowany == [Me], zas dla menadzera (patrz 6)
3) by nie meczyc sie w uprawnienia, dodajesz do listy kolumne manadzer
4) tworzysz tak jak Konrad podal Event Receiver na elemencie
5) Event receiver kopiuje info na temat mandzera osoby do danej kolumny
6) Menadzerowie maja widok where "Manager" contains [Me]
i rozwiaznie gotowe :)
inny sposob to wlasne widoki na liste na przyklad wykorzystujac SPGridView tworzysz wyswietlanie elementow listy i na podstawie aktualnych danych osoby zalogowanej wyswietlasz odpowiednie dane.
Gutek
http://blog.gutek.pl
http://dotnetblogs.pl
-
Ogolnie tutaj masz przyklad jak to zrobic z poziomu C#:
http://blogs.technet.com/stefan_gossner/archive/2009/0...
Gutek
http://blog.gutek.pl
http://dotnetblogs.plJakub Gutkowski edytował(a) ten post dnia 26.02.10 o godzinie 02:36
-
upsa to nie tutaj miala isc odpowiedz :)
ale skoro juz cos poszlo to, wydawalo mi sie ze podstawowe metadane sa zaciagane (ale to tylko mi sie wydawalo). Jezeli zas nie masz jakis danych ktore bys chcial miec to polecam napisanie jakiegos adaptera/event receivera czy cos w tym stylu ktory Ci to umozliwi (w szczegolnosci przeczyta te wartosci ktore Cie interesuja i jezeli beda dostepne).
Gutek
http://blog.gutek.pl
http://dotnetblogs.plJakub Gutkowski edytował(a) ten post dnia 26.02.10 o godzinie 02:35
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści .NET
- 1
- 2
- 3
- Następna »
