Miałem do czynienia z bardzo dziwną sytuacją, gdy próbowałem udostępnić element w bibliotece SharePoint Online użytkownikowi, który w ogóle nie miał dostępu do witryny. Po udostępnieniu elementu użytkownik otrzymywał odmowę dostępu, chyba że został dodany do grupy uprawnień „Członkowie”.
Ostatnio spotkałem się z dziwną sytuacją, gdzie użytkownik narzekał, że dostaje odmowę dostępu do witryny, mimo że gdy sprawdzałem jego uprawnienia, SharePoint wyświetlał, że ma przyznany poziom dostępu „Contribute”.
Ten post został zainspirowany sytuacją, z którą spotkałem się u jednego z moich klientów. Migrowałem SharePoint 2010 do SharePoint Online i w jednej witrynie klient posiadał wiele list, na których użytkownicy mogli tworzyć elementy. Za każdym razem, gdy ktoś utworzył lub zaktualizował element, przepływ pracy programu SharePoint Designer wysyłał im wiadomość e-mail z potwierdzeniem. Istotne było to, że listy korzystały z tej samej definicji przepływu pracy, skopiowanej dla każdej listy.
W usłudze SharePoint Online za każdym razem, gdy tworzysz bibliotekę i włączasz, lub nie opcję „Wymagaj wyewidencjonowania” przed edycją dokumentów, użytkownicy mogą otwierać pliki do współpracy w przeglądarkach lub w lokalnych aplikacjach Office. Gdy to zrobią, plik staje się zablokowany przed dostępem, np. przy próbie zmiany jego metadanych. Jeśli utworzysz przepływ Power Automate, którego celem jest zaktualizowanie metadanych pliku lub jego stanu zatwierdzenia, zakończy się niepowodzeniem podczas próby wykonania tej akcji.
W mojej codziennej pracy nad procesami biznesowymi w Office 365, konkretnie w SharePoint Online jedna rzecz denerwuje mnie najbardziej – mianowicie brak mechanizmów informowania mnie, że workflow się zawiesił, czyli jest w stanie „Suspended”.
Rozwiązania nie dostarcza ani Microsoft, ani też Nintex, z którym pracuję od dawna. Istnieją jedynie obejścia problemu, jednak okazują się niewystarczające, mnie zaś zależało na tym, by móc reagować proaktywnie, a nie reaktywnie na każde zdażenie zawieszenia się przepływu.
Czy kiedykolwiek męczyłeś się z brakiem możliwości wyczyszczenia wartości z pól typu liczba, osoba lub lookup używając PowerApps? Ostatnio znalazłem się w takiej sytuacji. Logika biznesowa mojej aplikacji wymagała, by usuwać wartości z pól formularza, w tym właśnie liczbowych, osób i lookupów. Niestety przekonałem się, że nie jest to możliwe (albo, jeszcze nie).
Gdy budowałem intranet używając modern SharePoint zostałem zapytany, czy byłoby możliwe, by wyświetlać w nim informacje pochodzące z ich portalu facebook @workplace. Zacząłem szukać i przeglądać dokumentację po to tylko, by dowiedzieć się, że bez znaczenia będzie fakt, czy użyję podejścia modern, czy classic w SharePoint, @workplace i tak nie posiada gotowych skryptów, które mógłbym skopiować i wkleić do portalu, by móc np. wyświetlać dane z Newsfeed.
Niedługi czas temu, w trakcie rozmowy z klientem pojawił się temat budowy pulpitu, który miał służyć do monitorowania wykonania zadań w przepływie pracy. Chodziło o to, by w zależności od faktu wykonania zadania lub przekroczenia deadline’u wiersze odpowiadające zadaniom były wyróżniane innym kolorem. W pierwszej chwili pomyślałem o użyciu formatowania kolumn w liście z włączonym Modern Experience. Jednak wówczas zostało dodane kolejne wymaganie, by nie tylko formatować wiersze odpowiadające zadaniom, lecz również wiersze je grupujące, z uwagi na dużą ilość poszczególnych zadań i potrzebę monitorowania wykonania całej grupy zadań, bez konieczności każdorazowego przeglądania każdego pojedynczo.
Pomimo faktu, iż InfoPath już wielokrotnie został uśmiercony, a jego przyszłość definitywnie zakończona, dla wielu firm budowanie formularzy dla przepływów pracy, z użyciem tego narzędzia, jest czymś tak oczywistym jak praca z Excel. Jednakże, gdy formularze są tworzone dla rozwiązań pracujących w Office 365 i SharePoint Online, ograniczenia i limity formularzy InfoPath są bardzo widoczne i stają się prawdziwym problemem.
Jakiś czas temu zmagałem się z problemem przekraczania dopuszczalnego rozmiaru instancji workflow (tutaj), który to był bezpośrednio związany z wielkością formularza InfoPath wraz z rozmiarem dołączonych do niego plików. Najbardziej oczywistym rozwiązaniem, jakie wówczas przyszło mi do głowy, było przeniesienie załączników z formularza do biblioteki dokumentów w SharePoint, jednak jak się okazało, nie było to łatwe do zrobienia z uwagi na algorytm, jaki jest używany w InfoPath do obsługi załączników.
Ostatnio znalazłem się w sytuacji, gdy po utworzeniu nowej Modern Site (to była Team Site), moje konto, które pomimo faktu bycia zarówno administratorem kolekcji witryn oraz administratorem SharePoint, nie miało dostępu do linków prowadzących do galerii witryny (solucji, szablonów list, web partów, czy funkcji zapisywania list i witryn jako szablonów). Co więcej, przy próbie dostępu do wybranej funkcji używając bezpośredniego linka i wykonaniu operacji np. wgrania solucji, otrzymywałem odmowę dostępu.