W jednej z firm produkujących akcesoria, moduł Projekty jest sercem procesu przygotowania nowego wyrobu. Każdy nowy produkt zaczyna życie jako kopia projektu wzorcowego: dział przygotowujący dokumentację techniczną duplikuje szablon, nadaje mu docelową nazwę i uzupełnia dane dopasowania. Dopóki jedna osoba nie zobaczyła komunikatu o braku uprawnień do utworzenia projektu, nikt nie zaglądał pod pokrywę.
Trzy poziomy zamiast jednego przełącznika
Rok wcześniej zbudowaliśmy tam model dostępu odpowiadający realnej strukturze pracy. Administrator widzi wszystkie projekty. Kierownik — te, które prowadzi. Uczestnik — tylko te, do których został przypisany zadaniem. To rozróżnienie nie wynikało z technologii, lecz z rozmowy o tym, kto za co odpowiada. Odoo nie ma takiego przełącznika w ustawieniach: poziomy powstają z reguł rekordów, czyli filtrów decydujących, które konkretne projekty widzi dany użytkownik.
Zamknięty krąg przy duplikowaniu projektu
Problem ujawnił się dopiero przy kopiowaniu szablonu. Jedna z reguł wymagała, aby użytkownik miał w projekcie przypisane do siebie zadanie — i obowiązywała nie tylko dla podglądu, ale też dla tworzenia. Przy duplikowaniu to warunek niemożliwy do spełnienia. W momencie sprawdzania uprawnień kopia jeszcze nie ma żadnych zadań, bo te powstają w następnym kroku. Klucz zostawał zamknięty w środku pokoju.
Naprawa nie polegała na poszerzeniu uprawnień, lecz na rozdzieleniu dwóch rzeczy, które zlały się w jedno. Reguła widoczności powinna ograniczać odczyt i nic więcej. Zapisu i tworzenia pilnują uprawnienia do modelu, nie filtry. Do warunków dołożyliśmy jeszcze jeden: autor projektu widzi to, co sam utworzył. Bez tego każda kopia szablonu na moment stawała się niedostępna dla osoby, która ją właśnie zrobiła.
Uprawnienia to nie to samo co interfejs
Drugie odkrycie było mniej oczywiste. Część funkcji Odoo jest ograniczona nie regułami, a warunkiem zapisanym w kodzie interfejsu — przycisk dodawania etapów w projekcie widzą wyłącznie administratorzy projektów, w każdej wersji od 16 do 18. Żadna konfiguracja uprawnień tego nie zmieni. Rozwiązaniem było wskazanie innej, wbudowanej ścieżki do tej samej operacji, dostępnej dla roli o węższych prawach.
Przy okazji audytu wyszło coś jeszcze: jedna z reguł wyglądała na aktywną, a nie obowiązywała nikogo. Skutek — pracownicy widzieli praktycznie wszystkie projekty w firmie, choć konfiguracja mówiła co innego.
Na koniec
Model uprawnień nie jest zbiorem zakazów, lecz odwzorowaniem odpowiedzialności. Warto go co jakiś czas przeczytać na nowo i sprawdzić, czy nadal działa tak, jak wygląda. Reguła, która niczego nie blokuje, jest równie kosztowna jak ta, która blokuje za dużo — tylko trudniej ją zauważyć.