Clean-Arch-Schichten für Cars: - lib/domain/entity/car.dart: UUID-id, accountId (Personalnummer), plate, active. Pendant zum Backend-Schema. - lib/domain/repository/cars_repository.dart: Port — listMine, create, update. Keine teamId/personalnummer-Parameter, der Account fließt serverseitig aus dem JWT. - lib/data/mapper/car_mapper.dart: API-DTO (built_value) → Domain. - lib/data/repository/cars_repository_impl.dart: konkrete Impl via generierter CarsApi (dio), mit DioException → CarsRepositoryException- Übersetzung. Feature-Cars-Refactoring: - CarsBloc nimmt jetzt die Domain-Repository-Schnittstelle. Events: CarLoad/CarAdd/CarEdit/CarDeactivate (statt CarDelete). Keine teamId-Parameter mehr. Kein authBloc-Bezug, Session-Expiry läuft über den globalen Provider-Stream. - CarsState sealed mit CarsInitial/Loading/LoadingFailed/Loaded. - Pages: car_management_page, car_management, car_card, car_fail_page, car_selection_page komplett auf die neue Entity und Event-Signaturen. - Alte lib/feature/cars/service/cars_service.dart und lib/feature/cars/repository/cars_repository.dart gelöscht. CarSelectBloc + Storage: - CarSelection.selectedCarId von int? auf String? umgestellt. - CarSelectionRepository persistiert die UUID jetzt als String; defensive Migration für noch vorhandene int-Werte (alte Pre-Migration-Installations) verwirft den Wert leise und erzwingt Neuauswahl. Konsequenz-Cleanup im Tour-Code (Phase-D-Vorbereitung): - Delivery.carId String? statt int?. - Tour.hasUndeliveredLoadedArticles / getFinishedDeliveries auf String carId. - _selectedCarId / int? carId / int selectedCarId in DeliveryOverview, LoadingCustomerPage/OverviewPage, Home, DeliverySelection/SortPage, DeliveryInfo/List, CustomSortDialog, SortableDeliveryList auf String umgestellt. - TourRepository ersetzt int.parse(carId)/int.tryParse-Zuweisungen direkt durch String. - lib/model/car.dart wird zum Re-Export der neuen Domain-Entity, damit Legacy-Imports während Phase-D-Übergang weiter compilieren. DI: - app.dart: CarsBloc bekommt CarsRepositoryImpl(locator<HolzleitnerApi>()) statt der alten CarsRepository(service: CarService()). Build (flutter build apk --debug) durch, flutter analyze ohne errors.
57 lines
1.6 KiB
Dart
57 lines
1.6 KiB
Dart
/// Fahrzeug eines Subunternehmer-Accounts — Domain-Entity.
|
|
///
|
|
/// Im Gegensatz zum alten `lib/model/car.dart` (int-ID,
|
|
/// ERPframe-Welt) hält die neue Entity:
|
|
/// * `id` als UUID-String (Backend-Konvention),
|
|
/// * `accountId` als Personalnummer (für Audit/Cross-Check, ist
|
|
/// redundant zur JWT-Identität aber explizit im Payload),
|
|
/// * `active`-Flag (Soft-Delete statt physisches Löschen).
|
|
class Car {
|
|
const Car({
|
|
required this.id,
|
|
required this.accountId,
|
|
required this.plate,
|
|
required this.active,
|
|
});
|
|
|
|
/// UUID des Fahrzeugs.
|
|
final String id;
|
|
|
|
/// Personalnummer des Account-Inhabers.
|
|
final int accountId;
|
|
|
|
/// Kennzeichen (z. B. "BGL-HZ 100").
|
|
final String plate;
|
|
|
|
/// Inaktive Fahrzeuge tauchen in `GET /me/cars` standardmäßig
|
|
/// nicht auf — sie bleiben aber als FK-Anker für historische
|
|
/// Audit-Einträge in der Datenbank.
|
|
final bool active;
|
|
|
|
Car copyWith({String? id, int? accountId, String? plate, bool? active}) {
|
|
return Car(
|
|
id: id ?? this.id,
|
|
accountId: accountId ?? this.accountId,
|
|
plate: plate ?? this.plate,
|
|
active: active ?? this.active,
|
|
);
|
|
}
|
|
|
|
@override
|
|
bool operator ==(Object other) =>
|
|
identical(this, other) ||
|
|
other is Car &&
|
|
runtimeType == other.runtimeType &&
|
|
id == other.id &&
|
|
accountId == other.accountId &&
|
|
plate == other.plate &&
|
|
active == other.active;
|
|
|
|
@override
|
|
int get hashCode => Object.hash(id, accountId, plate, active);
|
|
|
|
@override
|
|
String toString() =>
|
|
'Car(id: $id, accountId: $accountId, plate: $plate, active: $active)';
|
|
}
|