Week 13 Update: Final Presentation Preparation & Client Follow-Up

Progress Summary

This week, the team is focused on finalizing the project presentation (due May 8) while continuing to follow up with the client to complete the pending Client Evaluation Form.

Key Updates

1. Client Evaluation Status:
• Still awaiting submission of the evaluation form
• Sent 2 follow-up emails this week with polite reminders
2. Presentation Preparation:
• Outline finalized with the following sections:
• Project Summary: Original goals vs. final deliverable
• Achievements
• Challenges
• Demo
3. Documentation:
• Compiled technical documentation for handover, including:
• Updated API endpoints (§API Documentation)
• Database schema revisions (§Database Data Dictionary)

Sprint Backlog List

Task	Status	Owner	Documentation Reference
Finalize presentation slides	In Progress	All	§Technical Documentation
Prepare live demo scenarios	In Progress	John & Rain	§Frontend Components
Compile challenge/resolution summary	In Progress	Albert	§Project Retrospective
Follow up with client for evaluation form	Ongoing	Albert	N/A
Finalize deployment checklist	Pending	Albert	§VIII Kubernetes Deployment
Test demo environment stability	In Progress	John	§Kubernetes Deployment/Testing
Update GitHub repository with final code	Pending	Albert	§Version Control

Next Steps

1. Presentation Dry Run: Scheduled to test timing and demo stability
2. Deployment Readiness: Ensure staging environment mirrors production
3. Client Communication: Continue gentle follow-ups for evaluation form submission

Reminders for Client

• The Client Evaluation Form is critical for course completion. We kindly request submission by May 15 at the latest.

Stay tuned for the final deployment update and project documentation!

We’re excited to showcase our work! 

Week 12 Update: Frontend-Backend Compatibility Breakthrough

Progress Summary

This week, the team achieved a critical breakthrough in frontend-backend compatibility for the graduate applicant rejection feature. By leveraging existing system patterns documented in §API Documentation/Endpoints and §Database Data Dictionary, we implemented a streamlined solution that aligns with the client’s requirements while avoiding unnecessary complexity.

Key Technical Adjustments

1. Frontend Modification

• Swapped POST /api/applications/{id}/reject with POST /api/applications/{id}/close endpoint (§API Documentation §5.2)
• Removed rejection reason input field to match the close endpoint’s parameters
• Updated UI button logic in FormButtons.vue (§Frontend Components):

2. Backend Validation

• Confirmed status_id updates correctly via the close endpoint (§Database Entity Relationship Diagram)
• Retired unused rejected_at and rejection_reason columns from previous implementation

3. Database Sync

• Verified status_id transitions using DBeaver (§VII Database)

Sprint Backlog List

Task	Status	Owner	Documentation Reference
Modify frontend to use /close endpoint	Completed	Castro	§API Documentation
Remove rejection reason input UI	Completed	Castro	§Frontend Components/Dialog
Update backend close endpoint policy checks	In Progress	Quidet	§Backend Application/Policies
Validate status_id persistence	Completed	Domingo	§Database Data Dictionary
Prepare client demo scenarios	Pending	Domingo	§Technical Documentation/Versioning
Update API documentation for /close usage	Pending	Quidet	§API Documentation
Conduct cross-browser compatibility testing	Not Started	Domingo	§Kubernetes Deployment/Testing

Client Presentation Plan

Demo Focus Areas

• Show status_id updates in real-time via DBeaver (§VII Database)
• Demonstrate admin workflow using the modified button (§Frontend Components)
• Highlight reduced development time by reusing existing endpoints (§System Architecture)

This solution adheres to the original project constraints while utilizing documented patterns from §API Documentation and §Frontend-Backend Integration. The team is now positioned nearing finalizing documentation and can currently proceed with client evaluation.

Week 11 Update: Graduate Applicant Rejection Feature Progress

Breakthrough in Frontend-Backend Integration

This week marks a significant turning point in our development of the graduate applicant "Reject Anytime" feature. After encountering persistent state management issues where rejection status would revert upon page refresh, our team has identified and implemented a solution that leverages existing system architecture rather than creating new components.

Technical Discovery

The breakthrough came when our development team conducted a deeper analysis of the database schema and discovered that the application was already using a status_id field to track different stages of graduate applications. This field serves as the central source for an applicant's current status in the system.

The issue stemmed from our frontend implementation not properly utilizing this existing field. Instead of creating a new data structure to track rejection status, we've now modified our approach to leverage the established status_id pattern

Integration Strategy

This discovery allows us to:

1. Retain all the backend rejection functionality we've already implemented
2. Simplify the frontend implementation by using existing status management patterns
3. Ensure persistence across page refreshes since the status is properly stored in the database
4. Maintain consistency with the existing application workflow

The team is particularly excited about this approach as it represents a more elegant solution that aligns with established system patterns rather than introducing new complexity.

Sprint Backlog List

Objective: Finalize frontend integration with backend status_id implementation for persistent state management.

Looking Ahead

With this breakthrough in understanding the frontend-backend interaction model, we're now positioned to finalize the feature implementation. Next steps include documenting the status workflow for future developers.

This experience has provided valuable insights into the existing system architecture that will benefit future feature development beyond just the current rejection functionality.

Week 10 Update: Progress on the Graduate Applicant "Reject Anytime" Feature

Overview

This week, the team shifted focus to the frontend implementation of the "Reject Anytime" feature for graduate applicants. While significant progress was made, an issue emerged where rejected applications revert to their previous state upon refreshing the website. The team is actively investigating and addressing this issue to ensure a seamless user experience.

Sprint Backlog

Below is the current status of tasks for this sprint:

Challenges

State Persistence Issue

The rejection status reverts upon refreshing the page. This is likely due to a mismatch between the frontend state management and backend API responses. The team is currently debugging this issue and plans to implement a fix by syncing state with backend data on page load.

Next Steps

1. Resolve the state persistence issue by ensuring proper synchronization between frontend and backend.
2. Finalize and test the frontend rejection dialog component.
3. Conduct end-to-end testing of the feature in staging to ensure functionality aligns with requirements.

The team remains committed to resolving these challenges promptly and delivering a robust feature.

Week 9 Software Testing

Software Testing for CarSurvey PH

Link to software testing: CarSurvey PH - Software Test Report 02

Software evaluator: John Domingo

Week 9 Update: Graduate Applicant "Reject Anytime" Feature

Progress Overview

This week, we focused on implementing the fallback option for the "Reject Anytime" feature for graduate applicants. While the backend portion of the feature has been successfully completed, there have been delays in the frontend development. As a result, we will not be able to showcase the full feature during software testing scheduled for this Thursday. Instead, we will demonstrate the backend functionality using PHPUnit tests to verify that super admins can reject graduate applicants.

Sprint Burn-Down Chart

Below is the sprint burn-down chart for this week. The chart highlights the delay in completing frontend tasks, which has caused a deviation from the planned progress:

Sprint Burn-Down Chart: Graduate Applicant Reject Anytime Feature

Sprint Backlog

Here is the status of tasks for this sprint:

Backend API endpoint for rejection - Completed

Database schema migration - Completed

Policy updates for rejection functionality - Completed

PHPUnit tests for backend functionality - Completed

Frontend rejection dialog component - In Progress

Frontend validation rules integration - Pending

Product Velocity

• Tasks Planned: 6
• Tasks Completed: 4
• Velocity: 67% completion rate this sprint.

The team is working to address delays in completing frontend tasks and aims to catch up in the next sprint.

Next Steps

• Finalize the frontend rejection dialog component and validation rules by early next week.
• Conduct end-to-end testing of the entire feature once frontend integration is complete.
• Prepare for deployment to staging and production environments per §Kubernetes Deployment steps.