Zaproszenia do projektu

Główny README.md już opisuje cały przepływ zaproszeń od początku do końca (token, wygaśnięcie 7 dni, ścieżki akceptacji zalogowany-vs-niezalogowany, dlaczego mail z zaproszeniem albo przechodzi przez normalny pipeline powiadomień, albo dedykowany jednorazowy ProjectInvitationMail, w zależności od tego, czy adres już ma konto). Ta kategoria tego nie powtarza — to towarzysz "jak to rozszerzyć", ponieważ sam przepływ jeszcze nigdzie takiego nie ma.

Przewodniki, w kolejności, w jakiej faktycznie będziesz ich potrzebować

1. Zaproś wiele adresów narazZaproszenia do projektuZaproś wiele adresów narazPrzećwiczony przykład: zamiana formularza "Invite by email" dla pojedynczego adresu w masowy — wklej kilka adresów, dostań jedno zaproszenie na adres, z aw… — przećwiczony przykład zamiany formularza zapraszania pojedynczego adresu w masowy, śledzący zmianę przez hook, komponent, walidację i pętlę w Service.

Dwa powiązane, już udokumentowane elementy warte poznania przed dalszym rozszerzaniem tego przepływu: ../permissions/03-grant-a-custom-role-in-bulk.mdRole i uprawnienia (RBAC)Przyznaj rolę niestandardową masowoPrzećwiczony przykład: nowa akcja "Przyznaj wszystkim obecnym członkom" dla roli niestandardowej, tak aby właściciel/admin projektu mógł dać każdemu istnie… pokrywa stronę wstępnego przypisywania roli niestandardowej do zaproszenia, a ../notifications/04-add-a-dedicated-transactional-email.mdPowiadomienia (w aplikacji i mailowe)Dodaj dedykowany mail transakcyjnyPrzewodnik 2 pokrywa ponowne użycie generycznego szablonu NotificationMail (jeden współdzielony układ tematu/treści/przycisku akcji dla każdego Notificatio… pokrywa własny wzorzec ProjectInvitationMail dla dedykowanego, niezależnego od preferencji maila.

Architektura w jednym akapicie

ProjectInvitationService::invite() to jedyny punkt wejścia: najpierw sprawdza MailConfigurationService::isEnabled() (brak działającej poczty wychodzącej, brak zaproszeń — cała funkcja jest zabramkowana tym), usuwa dowolne istniejące oczekujące zaproszenie dla tej samej pary email/projekt (więc ponowne zaproszenie kogoś to po prostu ponowne wywołanie invite() — nie ma żadnej osobnej akcji ani endpointu "resend"), tworzy nowy wiersz ProjectInvitation z losowym 64-znakowym tokenem i expires_at na 7 dni, zapisuje poziom zaproszenia jako rolę systemową w pivocie project_invitation_role (w project_invitations nie ma kolumny role), obok wstępnie przypisanych ról niestandardowych (ProjectInvitation::tier() / customRoleIds(); role niestandardowe są zawężane przez RoleService::customRoleIds(), więc nie da się przemycić roli systemowej), i wystrzeliwuje ProjectInvited (konsumowany przez SendNotificationListener — zobacz ../notifications/README.mdPowiadomienia (w aplikacji i mailowe)Orbit informuje użytkowników o aktywności na dwa sposoby: powiadomieniem w aplikacji (dropdown z dzwonkiem) oraz mailem, w podziale na App\Enums\Notificati…). Zaakceptowanie go (acceptByToken()) dołącza użytkownika do projektu, przypisuje jego rolę systemową z $invitation->tier() przez RoleService::syncSystemRoleForMember(), dołącza wszelkie wstępnie przypisane role niestandardowe, i oznacza zaproszenie accepted_at — wywoływane albo automatycznie zaraz po zalogowaniu/rejestracji (jeśli obecny jest klucz sesji pending_invitation_token z kliknięcia linku mailowego przez niezalogowanego użytkownika), albo ręcznie przez wklejenie tokenu w JoinWithCodePanel w zakładce Members.