Klient wchodzi na listę obiektów

01Jedno spojrzenie: dziś kontra po zmianie

Po lewej jest dzisiejsza lista obiektów w Proofixie. Po prawej ta sama lista, te same obiekty, ten sam kod ekranu, tylko z innym kluczem grupowania. Reszta dokumentu to wyjaśnienie tej jednej różnicy i jej ceny.

Dla kogo i za ile

02Co powiedział Franek

Pięć wypowiedzi z dwóch dni. Pod każdą jedno zdanie o tym, co z niej wynika dla tej propozycji.

03Sześć znaczeń słowa „klient"

To jest najważniejsza tabela w całym materiale i jedyny powód, dla którego rozmowa o drzewie jest tak trudna. Słowo „klient" znaczy w Proofixie sześć różnych rzeczy, a napis „Klienci" na pasku nawigacji znaczy co innego u roli owner niż u szefa firmy. Jest dziś

Siódme, ukryte znaczenie: „Brak klienta"

04Dlaczego drzewo wyszło dziwnie

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

1. Lista obiektów grupuje sekcje po Twojej firmie, nie po kliencie. app/(auth)/(tabs)/objects.tsx:60 bierze (node as any).clients?.name, a hooks/useObjects.ts:31 w ogóle nie pobiera end_client_id. Dla szefa jednego tenantu daje to jedną sekcję z nazwą jego własnej firmy. Defekt
2. Nazwa klienta nie pojawia się nigdzie poza rejestrem Klienci. Ani na liście obiektów, ani na karcie zlecenia, ani w obecności, ani w raportach. Pełne przeszukanie po app/ i components/ daje 12 plików i żaden z nich to nie jest lista obiektów, zleceń, obecności ani raportów. Defekt
3. Zero filtrowania po kliencie w całej aplikacji. FilterState w zleceniach ma dokładnie trzy pola: status, priority, objectId (components/ui/FilterBar.tsx:11-27). Defekt

Skoro lista nie pokazywała żadnego podziału, jedynym sposobem, żeby zrobić sobie kategorie, było zrobienie ich z obiektów nadrzędnych. Stąd „utrzymanie terenów zewnętrznych" jako korzeń drzewa.

Warto to powiedzieć wprost: 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 w jego miejsce powstał rejestr end_clients. Propozycja A daje ten sam obraz na ekranie, tylko zbudowany na rejestrze, który już istnieje, a nie na parent_id.

05Pięć rzeczy, które naprawiamy zawsze

Te pięć defektów naprawia każda z trzech propozycji. Różnią się tylko tym, gdzie mieszka klient ze swoimi obiektami. Każdy defekt ma dowód i wskazanie makiety w tym dokumencie, na której go widać.

Makiety D1 i D2 są już wyżej, w sekcji 1: to jest ta sama para ramek, po lewej z etykietą DEFEKT. D3, D4 i D5 mają swoje pary ramek w sekcji 6.

06Jak to wygląda

Sześć ekranów, każdy w wersji web i mobilnej. Ekran 1 jest w sekcji 1, bo on decyduje o całej propozycji. Tutaj są ekrany od 2 do 6.

Ekran 2. Lista zawężona do jednego klienta

Kliknięcie chipa zawęża listę. Nic się nie chowa i nic nie znika z bazy, zmienia się tylko to, co widać. Chip z nazwą klienta niesie liczbę obiektów w jego gałęzi, więc skala jest widoczna zanim cokolwiek klikniesz.

Ekran 3. Zarządca: rejestr klientów jest pusty, więc chipy znikają same

Fikołki to persona zarządcy: firma sprząta własne obiekty i nie ma żadnych klientów w rejestrze. Wtedy grupowanie po kliencie nie ma czego pokazać. Aplikacja sama wybiera stronę: kiedy rejestr klientów jest pusty, rząd chipów i nagłówki sekcji po prostu się nie renderują, a ekran jest zwykłą płaską listą. Franek nie musi niczego ustawiać ani wybierać trybu.

Ekran 4. Formularz mówi, gdzie obiekt wyląduje (naprawa D3)

To jest ekran, na którym Franek stracił zaufanie do drzewa o 22:32. Obiekt trafił na listę główną, bo formularz w trybie korzeniowym tak działa, ale nie powiedział o tym ani przed zapisem, ani po. Naprawa jest czysto tekstowa: banner nad polami, widoczna wartość domyślna pola nadrzędnego i komunikat po zapisie, który nazywa miejsce.

Ekran 5. Wynik szukania niesie ścieżkę (naprawa D4)

Ten ekran jest pokazany na personie Filipa z Anfila, czyli na skali, o którą Franek pyta: kilkaset obiektów, po kilka pod-obiektów w każdym. Szukanie „cardio" znajduje pod-obiekty w kilkunastu siłowniach naraz. Dziś wszystkie wyglądają identycznie, bo znaleziony pod-obiekt renderuje się jako korzeń i nie ma przy nim żadnej informacji o tym, gdzie leży.

Ekran 6. Karta klienta z przyciskiem „Dodaj obiekt" (naprawa D5)

Na karcie klienta jest dziś sekcja Obiekty klienta z pickerem, który pozwala masowo zaznaczyć istniejące obiekty. Nie ma za to żadnego sposobu, żeby stamtąd utworzyć nowy obiekt, mimo że oba formularze obiektu obsługują już parametr ?endClient= i robią preselect klienta. Brakuje jednego przycisku.

07Dwie persony na jednym ekranie

Franek sam nazwał przyczynę całego zamieszania 17.08 o 22:48: „Patrzę sobie od dwóch stron. Czy to weźmie zarządca, czy weźmie ta firma usługowa. I to jest największy błąd w tej sytuacji." Propozycja A nie każe wybierać. Ten sam ekran obsługuje obie persony, a o tym, którą wersję widzisz, decyduje zawartość rejestru klientów.

08Odpowiedź na pytanie z 19.08

Odpowiedź jest trzyczęściowa, bo pytanie dotyczy trzech różnych sytuacji.

Jeszcze krócej: klienta wpisuje się raz na gałąź, nie raz na obiekt. Przy dwunastu siłowniach Benefit System to dwanaście kliknięć w pickerze albo dwanaście razy jedno kliknięcie w formularzu. Nie ma trzeciej drogi, w której aplikacja zgadnie klienta sama, bo nazwa obiektu nie mówi nic o tym, kto za niego płaci.

09Co to kosztuje

Trzy warstwy. Warstwa 1 to cała propozycja A i tylko ona jest potrzebna, żeby lista zaczęła cokolwiek mówić. Warstwy 2 i 3 są osobnymi decyzjami z osobną ceną.

Warstwa 1: sam widok Koszt mały

Cała warstwa 1 to jedna fala na froncie, cztery pliki plus jeden hook. Żadnej migracji, żadnej zmiany polityk RLS, żadnej zmiany w danych.

Warstwa 2: dane i serwer Koszt średni, do decyzji

Warstwa 3: osobna fala z testem PRZED i PO Koszt duży, nie teraz

Przepięcie obiektów, które dziś siedzą pod korzeniami-kategoriami w rodzaju „utrzymanie terenów zewnętrznych", wymaga zmiany parent_id. Dziś nie ma na to ani kontrolki, ani RPC, a sama ścieżka jest nieosłonięta: trigger dziedziczenia firmy, kontrola głębokości i limit liczby obiektów są BEFORE INSERT, ochrony przed cyklem nie ma w ogóle, a trigger integralności klienta milczy, gdy przenoszony obiekt ma pusty znacznik. To zawsze osobna fala z pomiarem przed i po, nigdy „jedna linia".

Ważne: propozycja A nie potrzebuje warstwy 3, żeby zadziałać. Stare korzenie-kategorie zostają tam, gdzie są, a lista i tak zaczyna grupować po kliencie. Warstwa 3 tylko sprząta historię.

10Czego to NIE robi

Uczciwe granice. Każda pozycja to rzecz, której po tej zmianie nadal nie będzie.

1. Nie daje przenoszenia obiektu w drzewie. Nie ma kontrolki, nie ma RPC, nie ma ochrony przed cyklem, a triggery głębokości, limitu i dziedziczenia firmy są BEFORE INSERT. Dlatego na makiecie formularza nie ma przycisku „Zmień" przy komunikacie po zapisie.
2. Nie pozwala ustawić klienta na pod-obiekcie z formularza. Klienta ustawia się z interfejsu tylko na obiekcie korzeniowym (new.tsx:283, [id].tsx:238). Jedyny wyjątek to picker na karcie klienta i on zostaje jedynym wyjątkiem.
3. Nie zmienia niczego w uprawnieniach. Są dwa rozłączne tory liczenia zakresu: role firmowe po parent_id, przedstawiciel klienta po znaczniku klienta. Propozycja A dotyka wyłącznie warstwy widoku i nie miesza tych torów. Zakaz z nagłówka migracji 20260807210000 zostaje nienaruszony.
4. Nie robi z liczb przy chipach liczb wiążących. Dopóki licznik liczy się w przeglądarce z zakresu zalogowanego, dwóch menedżerów zobaczy dla tego samego klienta różne liczby. Notka o tym jest dziś na karcie klienta, ale nie na liście, i tak zostaje do czasu warstwy 2.
5. Nie grupuje po rodzaju usługi. service_scope to wolny tekst bez słownika i bez ani jednego miejsca, które po nim filtruje. Grupowanie i nawigacja po nim to osobna, wyceniona opcja dodatkowa, nie część tej propozycji.
6. Nie daje przedstawicielowi klienta listy obiektów. Rola client nadal nie ma własnej listy ani karty obiektu i widzi swoje obiekty tylko przez obecność i patrole.
7. Nie porządkuje sześciu znaczeń słowa „klient" w całej aplikacji. Napis „Klienci" u roli owner nadal znaczy co innego niż u szefa firmy, a ekran „Uprawnienia klientów" nadal operuje na tabeli firm, nie na rejestrze klientów.
8. Nie filtruje po kliencie w zleceniach, obecności ani raportach. Zmiana dotyczy listy obiektów i karty klienta. Zlecenia nie mają nawet kolumny klienta.
9. Nie odwraca żadnej decyzji z 06.08. Klient dalej nie jest obiektem, utworzenie klienta dalej nie tworzy żadnego obiektu, a znacznik klienta dalej jest nullowalny.

11Co to odblokowuje

Ten sam join, którym lista obiektów dostaje nazwę klienta, jest jedynym brakującym elementem w kilku innych miejscach. Gdy nazwa klienta raz pojawi się w danych ekranu, można ją potem pokazać na karcie zlecenia, w nagłówku raportu i w widoku obecności, bez żadnej nowej kolumny w bazie. Domyka się przy tym rzecz, która dziś wygląda jak przeoczenie: przedstawiciel klienta nie widzi nigdzie nazwy klienta, którego reprezentuje, mimo że kolumna end_client_id fizycznie przychodzi do aplikacji w useMyClientUser przez select('*'), tylko nie jest zadeklarowana w typie i nikt jej nie renderuje. To jest jedno pole tekstowe w nagłówku jego pulpitu.

Drugą rzeczą, którą to otwiera, jest rozmowa handlowa z wątku z 19.08 o 15:17: skoro klient jest w systemie osobnym bytem z własnymi obiektami i własnymi przedstawicielami, to w przyszłości mógłby kupić Proofixa na swoje pozostałe obiekty, te, których 2FSG nie sprząta. To jest decyzja handlowa do podjęcia później i nic w propozycji A jej nie przesądza, ale też nic jej nie zamyka.

12Na czym to jest oparte