Trekking Management System

A Trekking Management Application that allows Admin, Trek Staff, and Users (Trekkers) to interact with the system based on their roles.

• In this video (0:28 onwards) I demonstrate the application.

• For the project report, please click here.

Roles

Role	Access
Admin	Pre-seeded account. Manages treks, approves/blacklists staff and users, views all bookings, and dashboard statistics.
Trek Staff	Registers and requires Admin approval before logging in. Manages assigned treks, updates slots/status, and views participant lists.
User (Trekker)	Registers and logs in immediately. Browses open treks, books trips, and views booking history.

Tech Stack

• Backend: Flask (Python)
• Database: SQLite, accessed via raw sqlite3 queries
• Auth: Flask's built-in session, password hashing via werkzeug.security
• Frontend: Jinja2 templates, Bootstrap 5

Project Structure (1st level view)

trekking-booking-system/
├── app.py                 
├── db.py                   
├── auth.py                 
├── admin_routes.py         
├── staff_user_routes.py    
├── templates/               
└── README.md

Application Data Flow

When a user interacts with the TrekkerApp, the data flows in a secure, logical sequence.

Here is one example (of the logic of booking treks) presented through a flowchart:

flowchart TD
    Start(("User Clicks<br>'Book Expedition'")) --> Browser["Browser sends POST<br>/user/book/1"]
    Browser --> App["app.py<br>Receives Request"]
    App --> Route["staff_user_routes.py<br>Handles Route"]

    subgraph Authentication ["Step 2: The Gatekeeper (auth.py)"]
        Route --> AuthCheck{"Is User Logged In<br>& Authorized?"}
    end

    AuthCheck -- No --> RedirectLogin["Redirect to /login"]
    RedirectLogin --> End1(("End"))

    AuthCheck -- Yes --> Logic

    subgraph BusinessLogic ["Step 3: Logic & Database (staff_user_routes.py & db.py)"]
        Logic["Connect to DB<br>via get_db"] --> CheckCap{"Check Trek Capacity"}
        CheckCap -- Insufficient --> FlashErr["Flash Error & Redirect"]
        FlashErr --> End2(("End"))
        CheckCap -- Sufficient --> Deduct["Deduct Requested Slots"]
        Deduct --> Insert["INSERT INTO bookings"]
        Insert --> Commit["Commit Transaction"]
    end

    subgraph ResponsePhase ["Step 4: The Response (Jinja Templates)"]
        Commit --> RedirectHistory["Flash Success &<br>Redirect to /user/history"]
        RedirectHistory --> FetchNew["Fetch Fresh Booking Data"]
        FetchNew --> Render["Render user_history.html<br>inherits layout.html"]
    end

    Render --> BrowserDisplay["Browser Displays<br>Updated Ledger"]
    BrowserDisplay --> End3(("End"))

    %% Custom Styles based on the app's UI palette
    classDef default fill:#FDFCF8,stroke:#d6d3d1,stroke-width:1px,color:#292524;
    classDef process fill:#064e3b,stroke:#047857,stroke-width:2px,color:#ffffff;
    classDef decision fill:#f59e0b,stroke:#b45309,stroke-width:2px,color:#ffffff;
    classDef endnode fill:#78716c,stroke:#57534e,stroke-width:2px,color:#ffffff;

    class App,Route,Logic,Deduct,Insert,Commit,RedirectHistory,FetchNew,Render,Browser,BrowserDisplay process;
    class AuthCheck,CheckCap decision;
    class Start,End1,End2,End3,RedirectLogin,FlashErr endnode;

Loading

Author

Naini Diwan

• GitHub: @23f3001480
• GitHub (alt): @Naini-Diwan
• LinkedIn: https://www.linkedin.com/in/naini-diwan-profile786/
• Portfolio: Website