Nawigator i zapisane widoki

01Werdykt i jeden obrazek

Ten dokument opisuje jeden z trzech wariantów. Wszystko, co jest tu opisane jako Jest dziś albo Defekt, ma dowód w kodzie albo w migracji. Wszystko inne jest oznaczone Propozycja i ma cenę w sekcji 9. Nic z tego nie jest wdrożone.

Najważniejszy obrazek: dziś kontra po zmianie

Zestawienie pokazuje dzisiejszą skalę: 22 obiekty, 15 na liście głównej. Liczby na makietach są przykładowe, poza tymi, które wprost cytuję z audytu (28 obiektów na LIVE, 12 z rodzicem, maksymalna głębokość 2). W obu ramkach ukryty jest lewy pasek nawigacji, bo jest identyczny i zabierał szerokość. W nagłówku sekcji kod wstawia w tym miejscu długi myślnik, w tym dokumencie zastąpiony zwykłym, żeby dotrzymać zasady zero długich myślników.

02Co powiedział Franek

Sześć zdań Franka z dwóch dni. Pod każdym jedno zdanie o tym, co z niego wynika dla tej propozycji.

03Sześć znaczeń słowa klient

To jest tabela z audytu (sekcja 2). Nie jest ciekawostką. To jest wyjaśnienie, dlaczego przy tej aplikacji da się zgubić: słowo klient znaczy tu sześć różnych rzeczy, a napis Klienci na pasku nawigacji znaczy co innego u roli owner niż u szefa firmy.

Konsekwencja dla tego dokumentu: wszędzie dalej Twoja firma oznacza 2FSG, a Klient oznacza wiersz w rejestrze end_clients, czyli Benefit System, Lidl albo Anfil. Nawigator z propozycji C stoi wyłącznie na tym rejestrze.

04Dlaczego drzewo wyszło dziwnie

To nie jest uprzejme zdanie, tylko wniosek z trzech faktów z audytu:

1. Lista obiektów grupuje po Twojej firmie, nie po Kliencie. objects.tsx:60 bierze clients.name, a hooks/useObjects.ts:31 w ogóle nie pobiera end_client_id. Szef jednego tenanta dostaje jedną sekcję z nazwą własnej firmy. Defekt
2. Nazwa Klienta nie pojawia się nigdzie poza rejestrem. Ani na liście obiektów, ani na karcie zlecenia, ani w obecności, ani w raportach. Pełny grep end_client po app/ i components/ daje 12 plików i żaden z nich to nie te ekrany. Defekt
3. Zero filtrowania po Kliencie w całej aplikacji. FilterState w zleceniach ma trzy pola: status, priority, objectId (components/ui/FilterBar.tsx:11-27). Defekt

Pomysł z 22:35, żeby obiektem nadrzędnym był Klient, został już raz rozpatrzony i odrzucony 06.08 przez samego Franka. Tryb ?jako=klient został wtedy usunięty (objects/new.tsx:99), a zamiast niego powstał rejestr end_clients z decyzją: „Klient to nie jest obiekt. Klient to jest dla mnie numerek.” (migracja 20260806090000:4-8). Propozycja C daje ten sam obraz, o który chodziło, ale zbudowany na rejestrze, który już istnieje, a nie na parent_id.

Dodatkowy powód, żeby nie ruszać parent_id: przeniesienia obiektu w drzewie dziś nie ma, nie ma też RPC ani ochrony przed cyklem, a triggery głębokości, limitu obiektów i dziedziczenia firmy są BEFORE INSERT. Ścieżka UPDATE parent_id jest dziś całkowicie nieosłonięta (audyt 8.2, punkty 6 do 8).

05Pięć rzeczy, które naprawiamy zawsze

Te pięć naprawia każda z trzech propozycji. Różnica między A, B i C zaczyna się dopiero za nimi. Każda pozycja ma dowód.

D1 i D2 widać na zestawieniu w sekcji 1. D4 ma własny ekran w sekcji 6. Poniżej D3 i D5.

06Jak to wygląda

Od tego miejsca wszystkie makiety pokazują skalę po imporcie Filipa: 331 obiektów, z tego 312 u jednego klienta. Nawigator ma trzy sekcje: Moje widoki, Klienci, Miasta. Na webie jest to stała kolumna 268 px między paskiem nawigacji a treścią. Na telefonie ten sam nawigator jest dolnym arkuszem.

Ekran 1: nawigator, nic nie wybrane

Ekran 2: wybrany Anfil i miasto Poznań

Ekran 3: zapisanie widoku

Ekran 4: arkusz filtrów i lista z chipami

Ekran 5: skala Filipa, 312 obiektów pod jednym klientem

Ekran 6: szukanie ze ścieżką (naprawa D4)

07Dwie persony

Aplikacja nie musi pytać Franka, czy jest zarządcą, czy firmą usługową. Wystarczy, że patrzy na rejestr klientów. Pusty rejestr oznacza zarządcę i wtedy część nawigatora po prostu nie powstaje.

Decyzja W9 z audytu (sekcja 10.1, punkt 6) mówi wprost: wariantu zarządcy nie budujemy teraz, ale nie wolno niczego zahardcodować tak, żeby go zamknąć. Ta propozycja tego nie łamie, bo zarządca dostaje mniej sekcji, a nie inny produkt.

08Odpowiedź na pytanie z 19.08

Odpowiedź ma trzy części i żadna z nich nie brzmi „do każdego”.

Czyli praktycznie: 312 siłowni Anfilu nie trzeba klikać po jednej. Wchodzisz na kartę klienta Anfil, zaznaczasz je w zaznaczaczu i zapisujesz. Dwa masowe UPDATE, jeden zapis (hooks/useEndClients.ts:180-214).

09Co to kosztuje

Trzy warstwy. Rosną nie tyle pracą, co ryzykiem. Szacunki są w dniach roboczych jednej osoby i są szacunkami, a nie ofertą.

Warstwa 1: sam widok Koszt

Warstwa 2: dane i serwer Koszt

Warstwa 3: osobna fala, nie razem z resztą Koszt

10Czego to NIE robi

Uczciwe granice. Każda pozycja jest po to, żeby nie było niespodzianki po wdrożeniu.

1. Nie zmienia tego, że klienta ustawia się z interfejsu tylko na obiekcie korzeniowym. Warunki !parentId w new.tsx:283 i !detail.parent_id w [id].tsx:238 zostają. Jedyny wyjątek to zaznaczacz na karcie klienta, tak jak dziś.
2. Nie dodaje przenoszenia obiektu w drzewie. Nawigator zawęża listę, ale niczego w drzewie nie przestawia. Przeniesienie to warstwa 3 i osobna fala.
3. Nie naprawia tego, że trigger integralności milczy przy end_client_id = NULL. Odtagowanie nadal nie zostanie zablokowane niczym.
4. Nie miesza dwóch torów liczenia zakresu. Role firmowe nadal liczą po parent_id przez get_my_subtree_ids(), a przedstawiciel klienta po tagu przez get_client_object_ids_for(). Nawigator jest warstwą widoku nad tym, co użytkownik i tak widzi, a nie nowym źródłem uprawnień. Nagłówek migracji zabrania podpinania prymitywów odwrotnych pod rolę client i tego nie ruszamy.
5. Nie grupuje po rodzaju usługi. service_scope to wolny tekst bez słownika i bez ani jednego miejsca w kodzie, które po nim filtruje. Osobna wycena wyżej.
6. Nie daje przedstawicielowi klienta własnej listy obiektów. Rola client nadal nie ma listy obiektów ani karty obiektu, widzi je tylko przez obecność i patrole. Nawigator jest ekranem dla firmy, nie dla klienta.
7. Nie dodaje filtru klienta w zleceniach. orders nie ma kolumny klienta, orders.object_id jest NOT NULL. Filtr zleceń po kliencie wymaga joina przez obiekt i jest osobną pozycją, nieujętą w tej wycenie.
8. Nie odwraca decyzji z 06.08. Klient nie jest obiektem i nie staje się nim w tej propozycji. Jest pozycją w nawigatorze, czyli dokładnie tym „numerkiem”, o którym Franek mówił.
9. Nie zastępuje zakładki Obiekty ani rejestru Klienci. Oba ekrany zostają tam, gdzie są. Nawigator dokłada kolumnę, a nie zabiera wejście.

11Co to odblokowuje

Jeden join do end_clients na liście obiektów jest tanią rzeczą, która otwiera kilka drzwi naraz. Ta sama nazwa klienta może potem stanąć na karcie zlecenia, w obecności i w raportach, bo dziś nie ma jej nigdzie poza rejestrem. Domyka się też sprawa, która wygląda dziś dziwnie: przedstawiciel klienta nie widzi w interfejsie nawet nazwy klienta, którego reprezentuje, mimo że kolumna end_client_id fizycznie przychodzi do aplikacji w useMyClientUser przez select('*') i tylko nie jest zadeklarowana w typie ani nigdzie renderowana (audyt 6.2). To ten sam join i ta sama godzina pracy. Osobno, jako decyzja handlowa na później, zostaje wątek z 19.08 o 15:17: klient taki jak Anfil mógłby kiedyś kupić aplikację na swoje pozostałe obiekty, a wtedy nazwa klienta widoczna po obu stronach przestaje być kosmetyką i staje się częścią oferty.