Większość aplikacji zakłada, że użytkownik jest jedną rzeczą: kupującym albo sprzedającym. Klientem albo dostawcą. Konsumentem albo twórcą.
juz-ide.pl nie może tego założyć. Pani Ania z Michałowa może w tej samej chwili szukać kogoś do malowania ściany (jest klientem) i oferować lekcje angielskiego (jest usługodawcą). I być wolontariuszką na zebraniu osiedlowym (jest uczestnikiem społeczności).
Jedna osoba. Trzy role. Jednocześnie.
Problem z rolami jako tożsamością
Kiedy „rola” jest właściwością konta użytkownika — masz problem przy każdej platformie dwustronnej.
Na Allegro jesteś kupującym albo sprzedającym — ale możesz być oboma w różnych transakcjach. Na Uber Eats dostarczasz albo zamawiasz — ale ta sama aplikacja obsługuje kierowców i klientów, bo to zazwyczaj różne konta.
juz-ide nie może wymagać dwóch kont od tej samej osoby. Mieszkaniec Starachowic ma jedno konto, jedno zameldowanie, jedną tożsamość w systemie. Może tylko działać w różnych kontekstach.
Oddzielenie tożsamości od kontekstu
Rozwiązanie: tożsamość użytkownika jest stała i jedna. Kontekst działania jest zmienny i zależy od operacji.
Kiedy Pani Ania tworzy ogłoszenie o usłudze (lekcje angielskiego) — działa jako usługodawca. Kiedy zgłasza się do zlecenia malowania — działa jako zleceniobiorca. Kiedy zarządza wydarzeniem osiedlowym — działa jako uczestnik społeczności.
System nie pyta „jaka jest rola tego konta?” — pyta „w jakim kontekście ta osoba wykonuje tę operację?” i sprawdza, czy ma uprawnienia w tym kontekście.
Organizacja jako nowy aktor
Ostatnie dni listopada 2025 przyniosły nowy wymiar: co jeśli w aplikacji działa nie osoba, ale firma?
Zakład elektryczny z Michałowa może chcieć mieć konto firmowe: kilku elektryków, jeden profil usługodawcy, zlecenia przypisane do firmy a nie do konkretnego człowieka.
To inny model: konto firmowe jako osobna tożsamość, z własnymi właściwościami (adres firmy, branża, NIP) i własnymi możliwościami (może tworzyć usługi, może zatrudniać pracowników, może mieć uprawnienia moderacyjne jako firma).
Konto osoby i konto firmy mogą być powiązane (pracownik firmy), ale nie są tożsame. Żyją osobno i rozwijają się niezależnie.
Multi-actor w kontekście CASL i uprawnień
W systemie autoryzacji CASL podmiotem jest nie tylko userId, ale
actorContext — kombinacja użytkownika i kontekstu, w którym działa.
Uprawnienie brzmi: „użytkownik U działający jako usługodawca w dzielnicy X może edytować zlecenie, które sam stworzył”.
Nie: „użytkownik U z rolą usługodawcy może edytować zlecenie”. Rola stała się kontekstem działania, nie właściwością konta.