Instrukcja obsługi

1. Pobranie repozytorium

git clone https://github.com/winderdoot/io2_flatshare.git
git checkout develop
git pull

Po pobraniu najnowszych zmian z developa, polecam od razu wpisać następującą komendę zanim zaczniecie coś ruszać w kodzie. Podziękujecie mi później.

git update-index --assume-unchanged *repo_directory*/flatshare_server/.env

2. Dodanie sekretów

Trzeba wejść w visual studio, otworzyć solucję *repo_dir*/flatshare_server/flatshare_server.sln i wcisnąć prawym przyciskiem na projekt flatshare_server i wybrać opcję Manage User Secrets. Otworzy się plik json z sekretami, trzeba tam wkleić obiekt json z sekretami (otrzymacie go na DM).

3. Modyfikacja lokalnego .env do docker compose

Aby stripe-cli mógł skomunikować się z backendem w bezpieczny sposób, potrzebny jest plik *repo_directory*/flatshare_server/.env. Problem jest taki, że na githubie może być upubliczniona tylko atrapowa wersja tego pliku. Dlatego najpierw trzeba poprosić gita żeby ignorował dalsze zmiany w tym pliku:

git update-index --assume-unchanged *repo_directory*/flatshare_server/.env

A wkleić do środka zmodyfikowaną wersję pliku, którą dostaniecie na DM.

4. Uruchomienie serwera i bazy danych

Zostało uruchomienie docker compose'a i samego serwera:

# Uruchomienie serwisów w dockerze
# Jeśli jesteś na windowsie, najpierw uruchom docker desktop!
cd *repo_dir*/flatshare_server
docker compose up db azurite stripe-cli -d

# Następnie trzeba zainicjalizować bazę danych. Ten krok robimy tylko raz przed pierwszym uruchomieniem serwera.
# Pobranie CLI entity framework
dotnet tool install --global dotnet-ef
# Inicjalizacja bazy
cd *repo_dir*/flatshare_server/flatshare_server
dotnet ef database update

# Uruchomienie serwera lokalnie. WAŻNE aby nie zapomnieć o profilu http
cd *repo_dir*/flatshare_server/flatshare_server
dotnet run --launch-profile "http"

UWAGA

Jesli potrzeba zamknąć serwer i uruchomić aplikację jeszcze raz. To trzeba najpierw zamknąć kontenery i uruchomić je jeszcze raz przed restartem serwera. Trzeba to zrobić bo inaczej płatności nie będą rejestrować webhooków - nie dostaniecie żadnych wyjątków ale aplikacja nie będzie prawidłowo działać. Zamykanie dockera:

cd *repo_dir*/flatshare_server
docker compose down

Podstawowe informacje o naszym projekcie

Stos technologiczny:

• Backend: .NET 9 (Web API), Entity Framework Core
• Baza danych: PostgreSQL (w kontenerach Docker na start)
• Cloud storage: Azure Blob (np. do przechowania zdjęć pokoi)
• Frontend: React

Organizacja pracy:

• YouTrack

Plan Sprintów

Sprint 1: Fundamenty, Infrastruktura i Tożsamość (Identity)

Cel: Skonfigurowanie środowiska, bazy danych oraz uwierzytelniania.

• Przygotowanie docker compose'a dla bazy PostgreSQL.
• Inicjalizacja projektów frontend i backend oraz konfiguracja połączenia z bazą danych.
• Wdrożenie ustandaryzowanych odpowiedzi błędów API (np. timestamp, status, error, fieldErrors).
• Implementacja modelu użytkownika (klasa User oraz kompozycja ról TenantRole, LandlordRole).
• Realizacja rejestracji i bezpiecznego logowania (generowanie i walidacja tokenów JWT).
• Dwuetapowy mechanizm resetu hasła (żądanie i potwierdzenie).

Sprint 2: Core Użytkownika i Start Ogłoszeń (Listings CRUD)

Cel: Budowa profili użytkowników i umożliwienie właścicielom tworzenia ogłoszeń.

• Zapis i aktualizacja preferencji Lokatora powiązanych z rolą TenantRole (np. zwierzęta, palenie, budżet).
• Implementacja bazowego modelu domenowego dla ogłoszeń (Listing powiązany z Apartment i Room).
• Stworzenie endpointu do wystawiania ogłoszeń ze statusem początkowym DRAFT lub UNDER_REVIEW.
• Integracja zewnętrznego magazynu plików (Azure blob) dla zdjęć (zapisywanie samych URL-i w bazie).

Sprint 3: Zaawansowane Ogłoszenia i Wyszukiwanie

Cel: Domknięcie cyklu życia ogłoszenia i rozpoczęcie wyszukiwarki/dopasowań.

• Pełna obsługa cyklu życia ogłoszenia: przejścia między stanami ACTIVE, HIDDEN, ARCHIVED.
• Wdrożenie encji Unavailability do zarządzania okresami niedostępności pokoju (np. na czas remontu).
• Podstawowy endpoint pobierający dopasowane da lokatora mieszkania z użyciem stronicowania (page, size).
• Implementacja algorytmu wyliczającego matchScore na podstawie preferencji.

Sprint 4: Rezerwacja i płatność

Cel: Rozwinięcie wyszukiwania i rozpoczęcie interakcji wynajmu.

• Stworzenie obiektu Booking i endpointu inicjującego rezerwację (status PENDING_APPROVAL).
• Zarządzanie rezerwacją przez właściciela: endpointy do akceptacji (/accept) i odrzucania (/reject).
• Anulowanie rezerwacji przez lokatora (/cancel) i obsługa konfliktów terminów (błąd 409 Conflict).
• Stworzenie obiektu Payment i integracja z zewnętrznym systemem płatności (stany Initiated, Redirected, Succeeded/Failed).
• Automatyczna zmiana statusu rezerwacji na CONFIRMED po pomyślnej płatności.
• Wdrożenie bramki płatności przy akceptacji rezerwacji przez właściciela
• Automatyczne anulowanie opłaconych rezerwacji i inicjacja zwrotów w przypadku blokady konta właściciela przez admina.

Sprint 5: Moderacja i integracja z zewnętrznym API

Cel: Domknięcie obsługi rezerwacji oraz budowa modułu moderacji dla administratorów.

• Budowa obiektu ViolationReport dla zgłoszeń naruszeń (stany: Open, UnderReview, ActionTaken).
• Realizacja blokady konta przez administratora (zmiana statusu na BLOCKED i ukrycie ogłoszeń).
• Próba integracji z backendem przygotowanym przez naszych kolegów

Sprint 6: Powiadomienia i Finalizacja

Cel: Integracja bramek płatniczych, powiadomień oraz ostateczne szlify.

• Wdrożenie serwisu powiadomień (interfejs INotificationPort) do wysyłania maili/pushy po ważnych zdarzeniach biznesowych.
• Testy końcowe i opcjonalne wdrożenie aplikacji.