Merged

Author: shubhmgrg

doc/sprint3/NFR.pdf

@@ -0,0 +1,75 @@
+# EpiReady Sprint 3 Release Planning Meeting
+
+## Release Goal
+To implement comprehensive alert management and action tracking capabilities for the cold-chain logistics monitoring system, enabling users to receive real-time notifications, manage alert statuses, and maintain detailed action logs for audit trails.
+
+## Project Scope
+
+### Included Features
+
+#### 1. Alert Management System
+- **Purpose**: Complete alert lifecycle management with status tracking
+- **Details**: Alert creation, status updates (active, inprogress, resolved), alert deactivation, and comprehensive alert history with timestamps
+
+#### 2. Action History & Logging
+- **Purpose**: Detailed tracking of all actions taken on shipments and alerts
+- **Details**: ActionLog model for alert-related actions, ShipmentAction model for shipment operations, and comprehensive action history API endpoints
+
+<!-- #### 3. Manual Override Capabilities
+- **Purpose**: Allow users to manually control alert statuses and actions
+- **Details**: Alert status override functionality, action creation and management, and user permission-based access control -->
+
+#### 3. Real-time Alert Notifications
+- **Purpose**: Instant notification delivery through WebSocket connections
+- **Details**: Real-time breach alerts, temperature monitoring, and live status updates with socket-based communication
+
+#### 4. Organization Management System
+- **Purpose**: Multi-tenant organization support for team collaboration
+- **Details**: Organization creation, join code system, user organization association, and organization-based access control
+
+#### 5. Shipment Analytics & Visualization
+- **Purpose**: Data visualization and historical analysis for shipment monitoring
+- **Details**: Graphs tab with temperature/humidity charts, history tab with action logs and timeline, and interactive data visualization components
+
+### Excluded Features
+- **SMS/Text Alerts**: Limited to email notifications due to unnecessary api costs addition
+- **Change Password**: Axed due to safety and security concerns for users
+## Bug Fixes
+- Fixed alert status update functionality
+- Resolved action history display issues
+- Improved error handling for alert management operations
+
+## Non-Functional Requirements
+
+| Requirement    | Description                                                         | Measurable Criteria                          |
+|----------------|---------------------------------------------------------------------|----------------------------------------------|
+| **Performance** | Alert system responds within 500ms for email delivery             | 95% of email alerts delivered within 500ms    |
+| **Security**    | Alert access control and action logging                           | All alert operations require valid authentication |
+| **Usability**   | Intuitive alert management interface                              | Users can manage alerts in under 1 minute     |
+| **Reliability** | Robust email delivery and alert persistence                       | 99% alert delivery success rate               |
+| **Data Integrity** | Complete audit trail for all actions                            | 100% action logging accuracy                  |
+
+## Dependencies
+- **Real-time Communication**: Flask-SocketIO with eventlet
+- **Database**: PostgreSQL with Alembic migrations
+- **Frontend**: React with Socket.IO client
+- **Authentication**: JWT token-based with role-based access
+
+## Known Limitations
+- **Email Rate Limiting**: Maximum 2 emails per monitoring cycle to stay within free tier for email pushes
+- **Mock Data**: Temperature and humidity data still simulated rather than real sensor feeds due to missing OpenWeatherAPI
+- **Limited Email Customization**: Basic email templates without rich formatting
+- **No SMS Integration**: Text alerts not implemented due to service costs
+
+## Participants
+- **Frontend Team**: Bo, Shubham, David
+- **Backend Team**: Eric, Ansh
+- **Project Lead**: Team coordination and feature prioritization
+- **Stakeholder**: Founder consultation for feature requirements
+
+## Release Criteria
+- All alert management endpoints functional and tested
+- Email notification system operational with error handling
+- Action history tracking working for all user operations
+- Real-time notifications delivering alerts within 1 second
+- Manual override capabilities accessible to authorized users

doc/sprint3/RPM.md

@@ -0,0 +1,58 @@
+# EpiReady
+
+ > _Note:_ This document is meant to be written during (or shortly after) your review meeting, which should happen fairly close to the due date.      
+ >      
+ > _Suggestion:_ Have your review meeting a day or two before the due date. This way you will have some time to go over (and edit) this document, and all team members should have a chance to make their contribution.
+
+
+## Iteration 3 - Review & Retrospect
+
+ * When: July 20th, 2025
+ * Where: Online
+
+#### Decisions that turned out well
+
+* Implementing email alerts with Flask-Mail was successful and provides reliable notification delivery for critical temperature breaches. The integration with the existing socket system ensures real-time updates reach users immediately.
+* The action history and logging system provides comprehensive audit trails, which is crucial for medical logistics compliance and accountability.
+* Manual override capabilities give users control over alert management, improving the system's usability and trustworthiness.
+* The modular approach to alert management (separate models for Alert and ActionLog) allows for flexible future enhancements.
+
+#### Decisions that did not turn out as well as we hoped
+
+* We had to limit email notifications to 2 per monitoring cycle to prevent spam, which may not be sufficient for high-volume operations.
+* SMS/text alerts were not implemented due to the complexity of integrating third-party SMS services, limiting notification options.
+* The alert system still relies on mock data rather than real sensor feeds, which affects the authenticity of the monitoring experience.
+* The alert system still relies on mock data rather than real sensor feeds, which affects the authenticity of the monitoring experience.
+
+## Product - Review
+
+#### Goals and/or tasks that were met/completed:
+
+* Successfully implemented email alert system with Flask-Mail integration for temperature and humidity breach notifications
+* Created comprehensive alert management system with status tracking (active, inprogress, resolved)
+* Implemented action history and logging with ActionLog and ShipmentAction models
+* Added manual override capabilities for alert status management
+* Established real-time alert notifications through WebSocket connections
+* Created alert viewing interface with pagination and filtering capabilities
+* Implemented alert deactivation functionality for better user control
+* Added shipment analytics with graphs tab showing temperature/humidity charts and trends
+* Implemented history tab with comprehensive action logs and timeline visualization
+* Implemented organization management system with creation and joining functionality
+
+#### Goals and/or tasks that were planned but not met/completed:
+
+* SMS/text alerts were not implemented due to third-party service integration complexity and time constraints
+* Real-time push notifications for mobile devices were not implemented
+* Custom alert rules configuration interface was not developed - alerts use predefined conditions
+* Real-time push notifications for mobile devices were not implemented
+* Integration with real sensor data feeds instead of mock data was not achieved
+
+## Meeting Highlights
+
+Going into the next iteration, our main insights are:
+
+* The alert system foundation is solid and provides a good base for future enhancements. The modular design allows for easy addition of new notification channels and alert types.
+* We need to prioritize real data integration to make the system more valuable for actual cold-chain operations. Mock data limits the system's practical utility.
+* User feedback indicates a need for more sophisticated alert visualization and analytics to help identify trends and patterns in shipment issues.
+* The email rate limiting (2 emails per cycle) may need to be configurable based on user needs and operational requirements.
+* Future sprints should focus on data integration, advanced analytics, and mobile notification capabilities to make the system more comprehensive and user-friendly.

doc/sprint3/burndown.pdf

@@ -1,6 +1,6 @@
-import eventlet
-eventlet.monkey_patch()
-
+if __name__ == '__main__':
+    import eventlet
+    eventlet.monkey_patch()
 from flask import Flask, jsonify
 from flask_mail import Mail
 from flask_cors import CORS
@@ -10,7 +10,7 @@
 from config.database import init_db, db
 import os
 from flask_migrate import Migrate
-import models
+from models import user, shipment, temperature, alert, weather, shipment_action, chat, organization
 
 load_dotenv()
 
@@ -32,8 +32,9 @@ def create_app():
     app.config['MAIL_USE_TLS'] = True
 
     from socket_events import register_socketio_events
-    from models import user, shipment, temperature, alert, weather, shipment_action
-
+    
+    print("we are here")
+    
     migrate = Migrate(app, db)
     socketio.init_app(app)
     mail = Mail(app)
@@ -43,9 +44,9 @@ def create_app():
 
     register_socketio_events(socketio, app, mail)
     return app
- 
-app = create_app()
 
+app = create_app()
+ 
 @app.route("/health", methods=["GET"])
 def health_check():
     print("CORS_ORIGIN:", os.getenv("CORS_ORIGIN"))
@@ -58,5 +59,7 @@ def add_security_headers(response):
     response.headers['Content-Security-Policy'] = "frame-ancestors 'none';"
     return response
 
+
 if __name__ == '__main__' and os.getenv("FLASK_ENV") == "development":
+
     socketio.run(app, debug=True)

doc/sprint3/schedule.pdf

@@ -10,6 +10,8 @@
 from flask_mail import Message, Mail
 import eventlet
 
+eventlet.monkey_patch()
+
 def parse_temp_range(temp_range):
     """Parses a string like '2 to 8' into (2.0, 8.0)."""
     try:

doc/sprint3/sprint-03-review.md

@@ -22,31 +22,26 @@ def signup():
 
     Registers a new user.
 
+    Role of the user is by default manufacturer when registering.
+
     Request Body:
     {
         "email": "user@example.com",
         "password": "password123",
-        "role": "manufacturer"  // Optional: manufacturer, transporter, transporter_manager
     }
 
     Possible Error Responses:
     - 400 Bad Request: "Please type both email and password as they are both required."
-    - 400 Bad Request: "Invalid role. Must be one of: manufacturer, transporter, transporter_manager"
     - 400 Bad Request: "This email address is already registered as a user."
     """
 
     data = request.get_json(force=True)
     email, password = data.get("email"), data.get("password")
-    role = data.get("role", "manufacturer")
 
     if not email or not password:
         return jsonify({"error": "Please type both email and password as they are both required."}), 400
 
-    valid_roles = ['manufacturer', 'transporter', 'transporter_manager']
-    if role not in valid_roles:
-        return jsonify({"error": f"Invalid role. Must be one of: {', '.join(valid_roles)}"}), 400
-    
-    if not create_user(email, password, role):
+    if not create_user(email, password):
         return jsonify({"error": "This email address is already registered as a user."}), 400
 
     return jsonify({"message": "User registered successfully!"}), 200