phase002 complete

DESIGN.md

@@ -20,6 +20,7 @@ This table will contain information about the users of the app. Mostly used to
 know who updated what. This table will include:
 
 *   *Fields:* `name`, `email`
+*   *Required uniqueness:* `email` is unique case-insensitively.
 
 
 ### 2. Vehicle
@@ -29,7 +30,9 @@ track. They have no strict ownership relationship as they can be used/driven by
 multiple operators. The vehicle information will include:
 
 *   *Fields:* `make`, `model`, `year`, `color`, `vin`,
-    `licence_place`, `current_odometer`, `fuel_tank_size`
+    `licence_plate`, `current_odometer`, `fuel_tank_size`, `active`
+*   *Required uniqueness:* `vin` is unique and normalized to uppercase;
+    `licence_plate` is unique case-insensitively.
 
 ### 3. MaintenanceSchedule
 Configures the maintenance rules for a specific vehicle. This allows the
@@ -37,6 +40,8 @@ Configures the maintenance rules for a specific vehicle. This allows the
 actual history.
 *   *Fields:* `vehicle_id`, `maintenance_type`, `mileage_interval`,
     `time_interval`
+*   *Note:* `time_interval` is stored as integer days. The UI can display the
+    value as months or days later.
 *   *Relationship:* Belongs to Vehicle
 
 ### 4. FuelEntry
@@ -45,12 +50,11 @@ Records specific refueling events.
     `price_paid`, `date`, `updated_by_user_id` (Tracks who submitted)
 *   *Relationship:* Belongs to Vehicle
 
-### 5. MainetnanceEntry
+### 5. MaintenanceEntry
 Records maintenance and repair history.
-*   *Fields:* `vehicle_id`, `odometer` (at time of service), `description`
-    (Should exactly match a `maintenance_type` value from the
-    MaintenanceSchedule), `cost`, `date`, `updated_by_user_id` (Tracks who
-    submitted)
+*   *Fields:* `vehicle_id`, `odometer` (at time of service), `name` (Should
+    match a `maintenance_type` value from the MaintenanceSchedule), `notes`,
+    `cost`, `date`, `updated_by_user_id` (Tracks who submitted)
 *   *Relationship:* Belongs to Vehicle
 
 ## Data Relationships
@@ -71,7 +75,7 @@ Records maintenance and repair history.
 
 ### Scenario B: Maintenance
 1.  User navigates to `Vehicle#show`.
-2.  User fills form with Description, Cost, Date.
+2.  User fills form with Name, Notes, Cost, Date.
 3.  User submits -> `MaintenanceEntry` is saved to DB.
 
 ### Scenario C: Overdue Alerts
@@ -108,7 +112,7 @@ do not need high performance. SQLite should work fantastic in this case.
 
 ## Test framework
 
-The test framework is rspec. You can run the tests with `bin/rails test`
+The test framework is rspec. You can run the tests with `bundle exec rspec`.
 
 ## Vehicle ownership
 
@@ -142,6 +146,10 @@ can leave stubs though for that to happen. The notification service just
 requires a curl request so it is simple to add later. For now, just log it into
 the console so that we can test it is working.
 
+Vehicles should not be deleted because maintenance and fuel history must be
+preserved. If a vehicle should no longer appear in normal workflows, mark it
+inactive instead.
+
 For data access, it would be nice to have 'admin' and 'regular' users however
 that is a distinction that we do not yet need. Remember to keep things simple
 but flexible in the future. Do not wall us in with how code is done.
@@ -151,3 +159,13 @@ user editing the same entry at any time. The only possible issue that I can see
 is if we have two users in the same vehicle and they both submit a fuel
 entry. In this case, we would just delete one of the entries. At no point in
 time should two users be editing the same record.
+
+
+# Platform information
+
+Note that we are using Ruby 4.0.6 which is still "experimental" with
+Rails 8. This means that sometimes odd isues can come from gem version
+issues. For example, I already had to fix an error with the `csrf_meta_tags` in
+the erb templates. The error was nothing to do with the code but with the JSON
+gem which Rails requires to be less than version 3 and we had 3.0.2
+installed. This caused the signatures to be mis-matched and made things wrong.