![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 873 Pomógł: 25 Dołączył: 24.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
Hej
Każdy user jest przypisany do firmy. User jest też przypisany do roli ( może mieć wiele ról ). Chciałbym osiągnąć funkcjonalność gdzie: NP 1 ) Admin widzi wszystko: dokumenty, wszystkie combosy wypełnione wszystkim, etc NP 2 ) User widzi: dokumenty z jego firmy. Jeszcze nie wiem czy nagłówki dokumentów będę wiązał z userem czy z firmą. Ale dla tych dywagacji nie ma to większego znaczenia. Będę też miał pozycje dokumentu. Trzeba coś wymyślić aby metoda showDocumentElements(int DocumentId) nie pozwalała zobaczyć pozycji z nieswojego dokumentu Etc. Proszę Was o podpowiedz, kawałek kodu, coś co zobrazuje jak to powinno być napisane. Temat myśle bardzo uniwersalny i każdy z niego zaczerpie. Nie chciałbym tworzyć osobnych kontrolerów dla ról. Zastanawiam się czy nie wystawić serwisu jakiegoś, którego metody dostawałyby role usera i na ten podstawie pobierały z repozytorium odpowienie dane? ( na ifach ) |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 673 Pomógł: 106 Dołączył: 31.12.2008 Ostrzeżenie: (0%) ![]() ![]() |
Czyli tutaj:
Cytat showDocumentElements(int DocumentId) nie pozwalała zobaczyć pozycji z nieswojego dokumentu zamiast "zobaczyć pozycji z nieswojego dokumentu" powinno być raczej coś w stylu "zobaczyć tylko te pozycje w ramach dokumentu do których mamy dostęp". Zrozumiałem że chcesz to documentId weryfikować, jeśli chodzi o pobieranie z bazy tylko tych rekordów do których masz dostęp to sprawa się komplikuje i nie ma na to dobrego rozwiązania. Wiadomo, nie opłaca się pobrać wszystkich i na każdym wywoływać metody can więc jesteśmy zmuszeni zaszyć to w logice zapytania. Ja do tego celu używam query scopes. Jeśli chcesz mieć to w jednym miejscu to w modelu możesz sobie za pomocą DI doładować konkretne Policy, a w samym Policy tworzyć metody typu "editQuery" itp. - osobiście sam tak lubię robić, ponieważ wtedy uprawnieniami dla danego modelu steruję w jednej klasie. W modelu masz wtedy tylko np. scopeWhereUserCanEdit(...) { return $this->policy->editQuery(...); } lub scopeEditableBy(...) { ... } (kwestia nazewnictwa należy już do Ciebie). --- edit --- Swoją drogą jest to jeden z nie do końca przemyślanych use casów, które nadal nie są rozwiązane, a przynajmniej ich rozwiązanie nie jest sugerowane przez Laravel. A praktycznie problem ten występuje w każdym projekcie. Podobnie ma się sprawa z eloquent eager loading i sortowaniem wyników po kolumnie pochodzącej właśnie z ładowanej relacji. Moim zdaniem powinien być jakiś sprytny mechanizm w eloquent który pozwala na sterowanie czy obiekty pochodzące z relacji mają być wczytywane osobnym zapytaniem czy jako joiny. Oczywiście ten drugi wariant aktualnie trzeba robić samemu, a jego implementacja we frameworku pewnie byłaby uciążliwa dlatego wciąż jest to kwestia otwarta. No ale to taki mały offtop, Eloquent jest tutaj jednak pewnym słabym ogniwem w tym frameworku. Ten post edytował r4xz 26.01.2018, 20:19:22 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 9.10.2025 - 03:01 |