car-tracker/DESIGN.md

Vehicle Tracker Application Design

Goal

A web application to replace manual spreadsheet tracking of vehicle maintenance and fuel usage of a shared fleet.

Architecture & Philosophy

• Language: Ruby on Rails
• Style: Snake_case
• Principle: Keep it simple. Do not over-optimize. CRUD is the priority.
• Database: Relational, tracking "Events" linked to specific "Entities."
• Tests: We should be test driven in our development. No feature should be created without a test.

Data models

1. User

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

2. Vehicle

This table will contain information about the vehicles (assets) that we 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

3. MaintenanceSchedule

Configures the maintenance rules for a specific vehicle. This allows the "overdue" check to be automated by comparing the current schedule against the actual history.

• Fields: vehicle_id, maintenance_type, mileage_interval, time_interval
• Relationship: Belongs to Vehicle

4. FuelEntry

Records specific refueling events.

• Fields: vehicle_id, odometer (at time of fill), gallons_pumped, price_paid, date, updated_by_user_id (Tracks who submitted)
• Relationship: Belongs to Vehicle

5. MainetnanceEntry

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)
• Relationship: Belongs to Vehicle

Data Relationships

• Vehicle has_many MaintenanceSchedules
• Vehicle has_many FuelEntries
• Vehicle has_many MaintenanceEntries
• User has_many FuelEntries (as the actor)
• User has_many MaintenanceEntries (as the actor)

Data Flow

Scenario A: Fueling

1. User navigates to Vehicle#show.
2. User fills form with Odometer, Gallons, Price.
3. User submits -> FuelEntry is saved to DB.
4. current_odometer is updated on the Vehicle record.

Scenario B: Maintenance

1. User navigates to Vehicle#show.
2. User fills form with Description, Cost, Date.
3. User submits -> MaintenanceEntry is saved to DB.

Scenario C: Overdue Alerts

1. On Vehicle#show, query the most recent MaintenanceEntry.
2. Compare MaintenanceEntry.date vs Date.today.
3. If difference > 6 months, display alert message to User.

Note that there is in the MaintenanceSchedule data, there is a time_interval field that defines the length of time for maintenance. There is also a milage that should be used as well and it is an or operation for them.

User Authentication

Because this is an internal application, I plan on something like this:

The server will every month generate a key. This key will be printed out in a QR code format. The users will then scan the QR code to collect the key. When they make a request, this key is sent along with it and is used to verify the user. Ideally each user would use the QR code to prove that I know them, enter a name and then get a session token that is used instead of sending the raw QR code. The idea is that it is proof that I know who they are by them posessing information that only I have (the QR code) and then in the future they should use the token to prove who they are.

Again, because this is an internal application, there should not be any passwords. Users are not really created to be logged in, more because I need to track who is doing what with the equipment.

Database choice

I have no hard requirements. I would prefer the database to be easy to use for development. This application will really only ever have up to 100 users so I 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

Vehicle ownership

Vehicles can be used by multiple operators. We do not need to track who is driving though. We just want to know about who is submitting updates and enteries.

Rails information

$ rails --version
Rails 8.1.3.1

Deployment

This will be a local development deployment. Once we are ready, it will be packaged into a Docker container and put on a production server. This container is designed to run behind a reverse proxy that is already in place.

Final notes

The relationship between the user and vehicle is minimal. This is on purpose because we really are only using the user to track who is making changes. We do not really care if it is the actual driver or not.

For overdue alerts, we will send notifications to the users using a notification service. This is not yet set up so we will not worry about it. We 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.

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.

Each edit by the users will be a seperate database entry. There should be no 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.