Skip to content

Final Milestone Deliverables

Jump to bottom
Utku Yiğit Demir edited this page May 16, 2026 · 31 revisions

Final Milestone Report - Group 11

1. Meeting Notes

2. Project Documentation

3. Project Review

Executive Summary

  1. Project Status Summary:

    Social Event Mapper reached a stable final release state for the CMPE 354 Spring 2026 Final Milestone. The system now provides a complete social event discovery and participation platform across web, mobile, and backend services. Users can create events, discover events through list and map views, join public events, request access to protected events, receive invitations for private events, manage tickets, participate in discussions, submit reviews, report inappropriate content, and interact with notification flows.

    The final milestone expanded the MVP into a more complete product by adding advanced event-management capabilities such as map based discovery page, versioned event updates, participant reconfirmation after critical changes, route-based events, approximate location handling for protected events, badge/achievement features, audience-based discovery filters, localization, dark mode, and stronger admin/moderation support.

  2. Deliverable Status:

    All major final milestone deliverables were completed and integrated into the main branch. The backend API, web frontend, and mobile application are available through the final release package. The web application is deployed at socialeventmapper.com, the backend API is documented through Swagger UI, and the Android APK is published under the final milestone GitHub release.

    The team also completed supporting documentation, including final requirements, final design artifacts, sequence diagrams, API endpoint documentation, test execution reports, individual contribution pages, and release/setup instructions. Automated test reports were prepared for backend, frontend, and mobile, and additional Maestro E2E scenarios were added for critical mobile flows.

  3. Final Release Notes:

    The final release includes the following major improvements over the MVP:

    • Web and mobile event discovery with improved filtering, category handling, map-based browsing, and location-aware behavior
    • Event creation with point and route location support, image handling, privacy settings, audience attributes, and participation constraints
    • Event detail pages with mini-map/directions, join/request/invitation actions, discussion and review sections, report actions, and rating counts
    • Versioned event editing and reconfirmation flows for critical event updates
    • Ticket wallet and QR-based check-in support
    • Notification inbox and push/in-app notification flows
    • Badge and achievement system with profile integration
    • Public profile pages and profile asset support
    • Turkish/English localization across main surfaces
    • Dark mode and responsive UI improvements
    • Admin/moderation tools for reports, users, events, notifications, ratings, tickets, and badges

  4. Process Improvements:

    Compared to earlier milestones, the team improved coordination by using smaller feature branches, clearer GitHub issue scopes, more consistent PR review practices, and better separation of backend, frontend, and mobile responsibilities. The final milestone also benefited from more explicit API contracts, Swagger/OpenAPI documentation, and cross-platform alignment between web and mobile implementations.

    Testing became more systematic during the final milestone. Backend integration tests, frontend component/unit tests, mobile unit tests, and Maestro E2E scenarios were used together to validate critical user flows. The team also relied more heavily on manual end-to-end testing before the demo, especially for flows that involved multiple surfaces such as event editing, reconfirmation, tickets, notifications, and invitations.

  5. Final Milestone Demo Reflections:

    The final milestone demo showed that the project had evolved from an MVP into a feature-rich social event platform. The strongest parts of the demo were the complete event lifecycle, map-based discovery, route/location features, private/protected participation flows, ticketing, discussion/review interactions, and notification behavior.

    The demo preparation also helped reveal final UI and integration issues, especially around dark mode, event editing feedback, map-card scrolling, image handling, and synchronization between updated backend state and frontend views. Addressing these issues before the release improved the overall polish and reliability of the product.

  6. What Could Have Been Done Differently:

    Some complex features, especially event versioning/reconfirmation, ticketing, notifications, and route-based map behavior, could have benefited from earlier cross-platform planning. Implementing these near the final milestone created integration pressure between backend, web, and mobile teams.

    The team could also have maintained a more formal test-plan document earlier in the semester, especially for multi-step flows involving different user roles. In addition, UI consistency tasks such as dark mode, localization, and responsive behavior would have been easier if they had been treated as continuous requirements from the beginning rather than concentrated near the final release.

    Finally, more frequent demo-style rehearsals throughout development could have helped catch user-facing issues earlier and reduced the amount of final-week polishing needed.

4. Progress Based on Teamwork

4.1 Team Contribution Summary

Team Member Contributions (Summary) Major PRs/Issues
Utku Yiğit Demir (Backend) Implemented backend discovery eligibility filters, multi-select category filter, invitation detail endpoint, rating count exposure, backend localization, and fixed frontend dark mode regressions. PR #652, PR #644, PR #615, PR #613, PR #610, PR #588, PR #580, Issue #631, Issue #581, Issue #501, Issue #498, Issue #483
Cansu Er (Mobile) Implemented Turkish/English localization across all mobile screens, route-type events on the map, Photon location search, event discussion section, multi-select category filter, event photo editing, and map area selector. PR #658, PR #647, PR #640, PR #612, PR #572, PR #567, PR #563, Issue #641, Issue #614, Issue #509, Issue #488, Issue #485, Issue #466, Issue #458, Issue #445, Issue #433
Buğra Keser (Mobile) Implemented event map clustering and overlays, mobile dark mode, in-app notification center, host event editing and reconfirmation UI, invitation flow alignment, and added missing UI/unit tests. PR #657, PR #649, PR #630, PR #628, PR #611, PR #604, PR #594, PR #573, PR #568, PR #552, PR #549, PR #544, PR #539, Issue #592, Issue #591, Issue #553, Issue #515, Issue #491, Issue #477, Issue #461, Issue #459, Issue #457, Issue #433, Issue #418
Oğuz Özer (Frontend) Led frontend feature delivery across all screens: map/discover view, dark mode, notification inbox, invitation management, tickets, event editing and reconfirmation, discussion panel, audience filters, Photon migration, and profile badges. PR #655, PR #646, PR #635, PR #634, PR #624, PR #598, PR #596, PR #593, PR #590, PR #589, PR #587, PR #585, PR #577, PR #566, PR #565, PR #564, PR #562, PR #561, PR #559, PR #536, Issue #654, Issue #645, Issue #582, Issue #505, Issue #499, Issue #490, Issue #479, Issue #476, Issue #470, Issue #468, Issue #464, Issue #462, Issue #456, Issue #455, Issue #454, Issue #453, Issue #452, Issue #451, Issue #450, Issue #448, Issue #436, Issue #434, Issue #432, Issue #423, Issue #417
Sevde Pekköse (Mobile) Implemented mobile ticket wallet and QR check-in, private event creation, host/participant invitation flows, join request image attachments, public profile with badges, audience filters, event reporting, and Maestro E2E tests. PR #656, PR #632, PR #627, PR #623, PR #619, PR #609, PR #586, PR #579, PR #578, PR #574, PR #560, PR #550, PR #548, PR #532, Issue #620, Issue #506, Issue #503, Issue #500, Issue #497, Issue #480, Issue #474, Issue #473, Issue #472, Issue #471, Issue #469, Issue #465, Issue #463, Issue #437, Issue #433, Issue #426, Issue #416, Issue #403
Emine Türk (Frontend) Opened issues for Global Admin Panel Dashboard, Event Reporting Structure, Unified Notification Architecture, Event Discussion Section, and Image/PDF Attachments for Join Requests across frontend, mobile, and backend. Implemented multi-select category filter on frontend. PR #629, Issue #482, Issue #481, Issue #480, Issue #479, Issue #478, Issue #477, Issue #476, Issue #475, Issue #458, Issue #448, Issue #442, Issue #429, Issue #426, Issue #423
Kaan Ünsel (Backend/DevOps/Frontend) Implemented the backend notification system, ticketing and QR check-in, admin panel, versioned event reconfirmation, invitation backend, image attachments, event reporting, discussion system, and DevOps integrations (New Relic, W3C/OWASP, Swagger). PR #642, PR #637, PR #636, PR #633, PR #622, PR #621, PR #606, PR #600, PR #599, PR #584, PR #583, PR #575, PR #571, PR #557, PR #556, PR #555, PR #551, PR #535, PR #534, PR #531, PR #530, PR #529, PR #528, PR #523, PR #517, PR #516, PR #513, PR #512, PR #511, Issue #602, Issue #570, Issue #546, Issue #527, Issue #526, Issue #525, Issue #524, Issue #514, Issue #487, Issue #482, Issue #481, Issue #478, Issue #477, Issue #475, Issue #449, Issue #447, Issue #444, Issue #443, Issue #442, Issue #441, Issue #429, Issue #421
Mehmet Akif Yıldırım (Backend/Frontend) Implemented badge/achievement system, public profile APIs and frontend page, notification triggers, approximate location for protected events, audience attribute filtering, change-password endpoint, and Turkish/English web localization. PR #659, PR #653, PR #651, PR #648, PR #643, PR #638, PR #608, PR #607, PR #605, PR #601, PR #597, PR #576, PR #554, PR #545, PR #542, PR #541, PR #538, PR #533, PR #510, Issue #616, Issue #595, Issue #547, Issue #540, Issue #519, Issue #504, Issue #496, Issue #495, Issue #489, Issue #467, Issue #460, Issue #435, Issue #431, Issue #413

4.2 Status of Requirements

  • Completed: 1.1.4, 1.2.1, 1.2.2, 1.2.3, 1.3.1, 2.1.1, 2.1.2, 2.1.3, 2.1.5, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.3.1, 2.3.2, 2.3.3, 2.4.1, 3.1.1, 3.1.2, 3.1.3, 3.2.1, 3.2.2, 3.2.3, 3.3.1, 3.3.2, 3.4.2, 3.4.3, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.1, 4.3.3, 4.4.1, 4.4.2, 4.4.3, 4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.5.5, 4.5.6, 5.1.1, 5.1.2, 5.1.3, 5.2.1, 5.2.2, 5.3.1, 5.3.2, 5.4.1, 5.4.2, 5.5.1, 5.5.2, 5.6.1, 5.7.1, 5.7.2, 6.1.1, 6.1.2, 6.2.1, 6.2.2, 6.3.1, 6.3.2, 6.3.3, 6.4.2, 6.5.1, 6.5.2, 6.5.3, 7.1.3, 7.3.2, 7.4.2, 8.1.1, 8.3.1, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.2.1, 9.3.1, 9.3.3, 9.3.4, 10.1.1, 10.1.2, 10.1.3, 10.2.1, 10.2.4, 12.1.1, 12.1.2, 12.1.3, 13.1.1, 13.1.2, 13.2.1, 13.4.1

  • In Progress:

    • 1.1.1 — Phone number is collected on the registration form (auth_handler/dto.go), but registration verification is email-based; no SMS/phone OTP flow.
    • 1.1.3 — Login currently accepts username + password only (auth_handler/dto.go); phone-number and email-as-identifier login were not implemented.
    • 1.3.2 — Participation history tabs (Hosted / Attended) exist on the profile, but filtering by keyword / date / category / location is not exposed on the history view.
    • 2.1.4 — Image upload via presigned URLs is fully supported (CreateEventPage.tsx), but the alternative "choose from predefined icons" picker was not added.
    • 2.3.5 — Admin CategoriesAdminPage exists in the back-office; the end-to-end suggestion → admin approval → catalog insertion flow is not wired up because suggestion submission (2.3.4) is missing.
    • 3.4.1 — Backend CreateInvitations accepts a usernames array (event_handler.go:239) so bulk invite is supported at the API level, but the SRS-specified "upload a list of usernames" (CSV / file upload) is not implemented in the UI.
    • 4.3.2 — Changing privacy on an existing event triggers reconfirmation and moves approved participants to Pending status, but non-invited participants are not permanently removed (they can still reconfirm); the SRS-required loss-of-access for non-invited participants is partial.
    • 6.4.1 — Host reliability is computed as a Bayesian blend of hosted_event_score and participant_score (rating/helpers.go); explicit cancellation-rate weighting is not part of the formula.
    • 6.5.4 — Inappropriate comments can be removed through the admin moderation panel (admin_handler.go); a host-level "delete comment within my event" action is not exposed to non-admin hosts.
    • 6.5.5 — Users can delete their own review comments, but discussion comments lack edit/delete endpoints; the comment usecase is create + list only for discussion type.
    • 7.1.1 — FCM push (firebasepush/provider.go) and Resend email (email/provider_resend.go) adapters are both implemented, but email delivery is not wired into every transactional event flow (currently used mostly for auth OTPs and select invitation paths).
    • 7.1.2 — Mobile client stores a local push-toggle (notificationPreferenceService.ts); there is no backend notification_preferences table and no per-type toggle on web.
    • 7.2.1 — Event cancellation triggers notifications; time / location / constraints changes propagate via the reconfirmation flow rather than as dedicated "the event time changed" notifications.
    • 7.4.1 — Invited users receive in-app invitation notifications (invitation/service.go:notifyCreatedInvitations); the parallel email-invitation delivery path is not implemented.
    • 9.3.2 — Scan endpoint verifies JWT signature and ticket status before marking Used, but proximity / location validation against the host's geofence is not enforced.
    • 11.1.1 / 11.1.2 — Geospatial and search queries meet the target latency in production usage, but no documented benchmark / load test artifact pins the 300 ms / 200 ms SLOs.
    • 11.2.1 — System is deployed and serving concurrent users on socialeventmapper.com, but a formal concurrent-user load test is not documented.
    • 11.2.2 — Push notifications are dispatched per recipient through the FCM Send API; a batched SendMulticast (or equivalent) path is not implemented.
    • 13.2.2 — Invitation lists are stored in the database with FK constraints and authorization checks on every read, but the rows themselves are not encrypted at rest beyond the underlying managed-Postgres encryption.

  • Not Started:

    • 1.1.2 — No SMS / Twilio integration; phone-number verification code flow does not exist.
    • 2.3.4 — There is no API or UI to submit category suggestions (a category_suggestions table exists from an early migration but no end-to-end feature was built on top).
    • 2.4.2 — Marking custom tags as favorite for faster discovery is not implemented; tags are plain strings with no favorite flag.
    • 5.6.2 — Favorite locations can be defined and passed to discovery via query params, but the discover page does not automatically bootstrap its map center from a saved favorite location.
    • 7.3.1 — Hosts are not notified when a user submits a join request; only the requester is notified on approve/reject (7.3.2).
    • 8.2.1 — The "My Events → Past" tab lists archived participations but offers no search input over the archived/past list.
    • 8.2.2 — No "Clear History" / participation anonymization action exists on the profile.
    • 10.2.2 — EventReportStatus exposes only PENDING / REVIEWED / DISMISSED; the three SRS-specified outcome states (Approved (no violation) / Restricted / Removed) are not modeled as distinct values.
    • 10.2.3 — Generic event-cancellation notifications exist, but a dedicated "your event was removed due to policy violation" notification path for moderation outcomes is not implemented.
    • 12.2.1 — Event edits create a new version atomically via RunInTx, but there is no optimistic-locking version check or 409 Conflict response if two hosts edit the same event concurrently.
    • 13.3.1 — No database-backup configuration (cron, scheduled workflow, or managed-backup setup) is committed to the repo or deployment manifests.

4.3 API Endpoints

The final backend API documentation is available through the deployed Swagger UI at https://socialeventmapper.com/api/docs/. The complete endpoint coverage summary and four complex sample usage scenarios are documented on the dedicated wiki page: Final Milestone API Endpoints.

4.4 User Interface / User Experience

Artifacts

Screenshots

4.5 Utilized Standards

Compliance Summary

  • OpenAPI 3.1.0 — All public backend endpoints are described in docs/openapi/*.yaml and served through Swagger UI at socialeventmapper.com/api/docs/.
  • REST (RFC 7231) over JSON (RFC 8259) — Resource-oriented routes (/events, /profiles, /tickets, /invitations, /comments) with GET/POST/PATCH/DELETE verbs and application/json bodies; semantic 2xx/4xx/5xx status codes.
  • JSON Web Tokens (RFC 7519 / JWS RFC 7515) — Issued by backend/internal/adapter/in/jwt/issuer.go for authentication and by backend/internal/adapter/in/jwt/ticket_token_manager.go for QR-encoded ticket tokens.
  • OAuth 2.0 (RFC 6749) — Used as the client-credentials flow against Google for Firebase Cloud Messaging service-to-service auth in backend/internal/adapter/in/firebasepush/provider.go.
  • bcrypt password hashing — backend/internal/adapter/in/hasher/bcrypt.go (golang.org/x/crypto/bcrypt, configurable cost) satisfies SRS §13.1.1.
  • OWASP Top 10 / OWASP ASVS L2 — Documented mappings in docs/compliance-standards/security.md; controls include access-control checks, token rotation, parameterized SQL via pgx, security headers (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), and structured request logging.
  • W3C WCAG 2.1 AA accessibility — Documented mappings in docs/compliance-standards/accessibility.md; implemented via skip-links, aria-label/role attributes on navigation/forms, :focus-visible styling, prefers-reduced-motion handling, and emoji-plus-color category indicators (so meaning is not conveyed by color alone).
  • ISO 8601 / RFC 3339 date-time — All event time fields and timestamp responses are RFC 3339 strings with timezone offset (see docs/openapi/event.yaml, schema Event.start_time / end_time).
  • HTTP Accept-Language (RFC 9110 §12.5.4) — Locale negotiation for Turkish/English implemented at backend/internal/i18n/accept_language.go using golang.org/x/text/language.ParseAcceptLanguage; TR/EN catalogs live under backend/internal/i18n/locales/.
  • Firebase Cloud Messaging HTTP v1 API — Push notifications dispatched from backend/internal/adapter/in/firebasepush/provider.go using the v1 REST contract and OAuth2-signed service-account credentials.
  • PostgreSQL + PostGIS (OGC Simple Features for SQL) — Geo-indexed event locations are stored as GEOGRAPHY(POINT, 4326) (backend/migrations/000001_enable_postgis.up.sql, 000002_*.up.sql); radius and route queries use PostGIS spatial operators.
  • ISO/IEC 18004 (QR Code) — Ticket QR codes are generated through the qrcode library (mobile/src/components/ticket/DecorativeQrCode.tsx) carrying signed JWTs as payload.
  • Semantic Versioning (SemVer 2.0.0) — Final release tagged final-milestone (1.0.0) on GitHub Releases; mobile/package.json declares 1.0.0.
  • Conventional Commits 1.0 — All merged commits follow type(scope): message (feat(backend), fix(frontend), docs(openapi), test(mobile), chore(...), devops(...)).
  • CommonMark — All documentation (README.md, wiki, docs/) is written in CommonMark-compatible Markdown.
  • OCI / Docker Compose v2 — Multi-stage backend/Dockerfile, frontend/Dockerfile, and deploy/docker-compose.{local,dev,prod}.yml deploy artifacts conform to the OCI image spec.
  • CI/CD via GitHub Actions — .github/workflows/{backend-ci,frontend-ci,mobile-ci,deploy-dev,mobile-apk}.yml enforce build, test, lint, and coverage gates on every PR.
  • TypeScript + ECMAScript Modules (ESM) — frontend/tsconfig.json (module: "ESNext", "type": "module") and mobile Expo/React Native both target modern ESM.

Deep Dive

Standard: OWASP Top 10 / OWASP ASVS L2

  • Evidence:
    • docs/compliance-standards/security.md maps each OWASP Top 10 (2021) category to project controls.
    • Broken Access Control (A01): every event/participation handler runs an authorization check against the resolved user_id and event role before mutating state (e.g. backend/internal/application/event/service.go host-only edit guard; ProtectedRoute.tsx / AdminRoute.tsx on the web).
    • Cryptographic Failures (A02): passwords are hashed with bcrypt (hasher/bcrypt.go); JWTs are HS256-signed (jwt/issuer.go); ticket tokens are signed JWTs (jwt/ticket_token_manager.go) so a stolen QR cannot be forged.
    • Injection (A03): all database access goes through pgx parameterized queries; no string concatenation in backend/internal/adapter/in/postgres/*.go.
    • Security Misconfiguration (A05): nginx in nginx/nginx.dev.conf and nginx.local.conf sets Content-Security-Policy, X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy, and Permissions-Policy (camera/mic disabled, geolocation self-only) on every response; TLS 1.2/1.3 only with HTTP→HTTPS redirect; CORS is allow-listed per environment.
    • Identification & Authentication Failures (A07): bcrypt hashing with configurable cost; email verification is rate-limited; JWT exp enforced and refresh-token rotation implemented in the auth flow.
    • Security Logging & Monitoring Failures (A09): structured request logs (backend/internal/server/http.go middleware) and New Relic APM integration (PR #511) capture authentication failures and admin actions.
  • Reasoning: Social Event Mapper handles authenticated user data (profiles, private/protected events, invitation lists, tickets, push tokens) and acts as a host for user-generated content (events, comments, reports). OWASP Top 10 was chosen as the baseline because it is the de-facto industry checklist for web-app threat modeling, has direct mappings to our handler layer, and complements the SRS §13 security requirements with concrete acceptance criteria. ASVS L2 (the level recommended for apps that process sensitive personal data) was used to scope deeper controls — most visibly bcrypt hashing, parameterized SQL, security headers, and authenticated logging — so that the deployed service meets a recognized assurance baseline rather than ad-hoc "secure-feeling" code.

Standard: W3C WCAG 2.1 Level AA

  • Evidence:
    • docs/compliance-standards/accessibility.md maps WCAG success criteria to web/mobile implementation choices.
    • Perceivable: every interactive icon has an aria-label; category indicators use both color and an emoji glyph so meaning is not conveyed by color alone (1.4.1 Use of Color).
    • Operable: a skip-link is rendered at the top of frontend/src/components/AppShell.tsx; focus management uses :focus-visible outlines defined in frontend/src/styles/global.css; prefers-reduced-motion toggles map and badge animations off.
    • Understandable: form fields expose aria-invalid and aria-describedby on error; localized labels are sourced from frontend/src/i18n/locales/{en,tr}.json so the page lang attribute matches the rendered text (3.1.1 Language of Page).
    • Robust: semantic landmarks (<header>, <nav>, <main>, <footer>) in the web shell; React Native accessibilityLabel/accessibilityRole on touchable mobile components.
  • Reasoning: The platform's discovery, joining, and ticket-redemption flows must be usable by participants who rely on keyboard navigation, screen readers, or high-contrast / reduced-motion settings — particularly because the system is positioned as a community-building tool that includes newcomers and visitors. WCAG 2.1 AA is the standard required by most European public-sector procurement (EN 301 549) and is the level practical for a project of this scope; AAA would require concessions (e.g. 7:1 contrast everywhere) that are infeasible alongside the categorical color system. Demo feedback specifically called out the emoji-plus-color category cue as an accessibility win.

Standard: OpenAPI 3.1.0

  • Evidence:
    • Per-domain specs under docs/openapi/{auth,event,profile,badge,admin,category,notification,favorite_location,ticket,invitation}.yaml.
    • Specs are bundled and served at runtime through Swagger UI at socialeventmapper.com/api/docs/ (wired from backend/internal/server/http.go).
    • Every PR that adds or changes a backend endpoint updates the matching .yaml file in the same commit (visible across PRs #510, #533, #538, #545, #554, #576, #580, #588, #601, #605, #613, #615, etc.).
    • A Postman collection generator (PR #537) consumes the OpenAPI definition to produce a ready-to-run collection for manual API testing.
  • Reasoning: With backend, web, and mobile owned by different sub-teams, a single machine-readable contract was essential to prevent frontend/mobile drift from the backend implementation. OpenAPI 3.1.0 was chosen because it aligns with JSON Schema 2020-12 (so request/response shapes are validated the same way on both sides), is supported out-of-the-box by Swagger UI for live demo documentation, and is consumable by the Postman generator we use during manual QA. Treating the OpenAPI YAML as the source of truth — required by the convention in docs/conventions.md — made cross-stack reviews (e.g. the multi-select category filter epic across PRs #613 / web / mobile) faster, since reviewers could diff the contract first and the implementation second.

Standard: ISO 8601 / RFC 3339 date-time

  • Evidence:
    • docs/openapi/event.yaml declares start_time and end_time as string with format: date-time, requiring RFC 3339 strings (a strict subset of ISO 8601) including timezone offset.
    • All Go DTOs encode timestamps via time.Time's default JSON marshalling (RFC 3339 with offset).
    • Frontend and mobile clients parse the same format via the browser/JS Date constructor and Intl.DateTimeFormat for locale-aware display.
  • Reasoning: Event discovery, reconfirmation deadlines, ticket validity windows, and notification timestamps must remain unambiguous across the user's local timezone, the host's timezone, and the server's UTC clock. ISO 8601 / RFC 3339 carries timezone offset explicitly, which removes any reliance on "wall clock" assumptions and lets the mobile and web clients reformat for the viewer without re-querying the backend. This is especially important for route-based events and cross-timezone invitations.

4.6 Testing & Quality Assurance

Test Execution Reports

New Test Evidence

Impact Analysis

The final testing phase was not merely a verification of code completion, but a critical validation of the system's reliability and user-facing integrity. The transition from MVP to the Final Milestone focused on covering complex integration paths and real-world user behaviors.

  • Coverage: The expanded test suite ensures that every critical feature added during this final milestone is now fully covered, moving beyond basic logic into complex, multi-system flows:

    • Secure Ticketing & Entry Management: The entire lifecycle of digital ticketing—from ticket generation and QR token signing to secure host-side validation—is now fully covered. These tests ensure that only authorized participants can enter events, fulfilling a core security pillar of our final release.
    • Social Engagement & Moderation: Critical social interactions, specifically the Event Discussion (Q&A) and Rating System, are fully validated. This ensures that community interactions and feedback loops perform reliably across all surfaces, maintaining high data integrity for user-generated content.
    • Sophisticated Event Privacy: We have achieved comprehensive coverage for Join Request approval workflows and Event Invitations. These tests fully validate the complex permission logic required for private and protected events, ensuring that sensitive event data remains secure and accessible only to approved users.
    • Transactional Integrity & Notifications: New integration tests fully cover the Notification Broker and the underlying Unit of Work transactions. This guarantees that whenever a critical event occurs (e.g., a participation approval), the system reliably updates the database and triggers the corresponding push/in-app notification as a single, atomic operation.

  • Bug Detection: Automated testing directly caught several "silent" failures that manual testing would likely have missed:

    1. The Unit of Work Race Condition: During backend integration testing, we discovered a race condition where multiple concurrent "join requests" could bypass capacity limits. The tests revealed that database transactions were not sufficiently isolated. We resolved this by implementing row-level locking (FOR UPDATE), ensuring that even under heavy load, the event capacity is never exceeded.

    2. QR Token Synchronization: Maestro E2E tests identified a critical edge case where the ticket QR code would fail to refresh if the mobile app was kept in the background for more than 5 minutes. This would have caused major issues during live event check-ins. By catching this through E2E flows, we implemented a robust foreground sync logic before the final release.

  • Readiness: The current test suite confirms system stability through three distinct layers:

    • Resilience: The 100% pass rate of 681 mobile tests, 601 backend tests, and 189 frontend tests provides absolute confidence that the core platform is stable and regression-free.
    • End-to-End Integrity: Our 8 Maestro E2E scenarios serve as a "digital user," proving that the frontend, backend, and database work in perfect harmony across the most complex journeys.
    • Quality Benchmark: The combination of high coverage in business-critical areas and zero failures in the current suites signifies that the Social Event Mapper has reached the level of maturity required for a successful Official Release.

4.7 Demo Reflections & Notes

Notes Taken During the Demo

During the demo, several parts of the platform were received positively. One of the most appreciated aspects was the overall richness of the event model and the fact that the system goes beyond simple event creation and participation. In particular, the Turkish/English language option was seen as valuable because it makes the platform more accessible and practical for a broader range of users. The reconfirmation flow was also well received, since it adds transparency and trust when important event details change after participation.

The ticketing flow also stood out as a strong and memorable part of the demo. In particular, the ticket scan path was appreciated because it made the event participation model feel more concrete and realistic, showing that the platform supports not only event discovery and joining, but also actual on-site event entry and validation. This helped communicate that the system includes operational flows beyond a typical event-listing application.

Another positively received feature was support for route-based events and the ability to select multiple points. This made the platform feel more flexible and better suited for real-world event scenarios such as walks, tours, or multi-stop social activities. It showed that the system can handle different event structures rather than assuming that every event happens at a single fixed point.

We also observed positive feedback regarding the way categories are represented not only through color but also through emoji-based visual cues. This was especially meaningful because it aligned with accessibility considerations we had discussed in class, particularly the importance of not relying on color alone. This made the interface feel more inclusive and easier to understand for a broader range of users.

At the same time, we received feedback that the platform could benefit from an even stronger sense of community. One suggestion was to emphasize use cases where the platform helps people adapt to a new environment. For example, a user who has recently moved to a new city or country could use the platform not only to find events, but also to meet people and build social connections. This highlighted that the project has potential value not only as an event platform, but also as a community-building tool.

Reflections

The demo showed that the platform’s strongest qualities are its completeness, flexibility, and attention to real user flows. Features such as multilingual support, reconfirmation, route-based event modeling, and the ticket scan path helped demonstrate that the system is not limited to basic CRUD-style event management, but instead supports a more realistic end-to-end event experience.

The positive reaction to multiple-point event support confirmed that flexibility in event structure is meaningful to users. Similarly, the appreciation for the ticket scan flow showed that operational details can significantly strengthen the perceived realism and usefulness of the product. The feedback on emoji-and-color-based category distinction also reinforced that accessibility-aware design choices can make the system feel more thoughtful and user-friendly even at the interface level.

The demo also helped us identify several meaningful directions for future improvement. One of the clearest opportunities is to strengthen the platform’s community-building aspect. While the current event participation model is already strong, the product could become even more welcoming by introducing newcomer-oriented onboarding and more socially expressive event cues. For example, an “I’m new here” onboarding path, event tags such as “language-friendly,” “expat-friendly,” “students,” or “first-timers welcome,” and softer recommendation patterns like “people like you joined these events” could make the platform feel more socially supportive rather than purely functional.

Another important area is trust and safety. The platform already includes strong foundations such as privacy-aware participation flows, join requests, ticketing, and reconfirmation. However, this could be extended further with clearer host reliability signals, no-show or cancellation summaries, more visible moderation/reporting cues, and trust-oriented indicators such as “verified host” or “well-organized events.” These additions could help users make more confident participation decisions.

We also reflected on the value of improving the post-event experience. At the moment, the platform is strongest at helping users discover and join events, but the community loop after an event could be more visible. Features such as “stay connected” suggestions, post-event follow-up discussion threads, recurring community/event series, or recommendations based on previously attended groups could help transform one-time participation into ongoing social engagement.

On the product side, the demo also pointed to opportunities for smarter and more personalized discovery. The current discovery system is already technically capable, but it could evolve further by incorporating soft ranking signals such as past participation behavior, favorites, language preference, age group, or category preference. Similarly, host-side tooling could be improved with features like waitlists, scheduled announcements, participant segmentation, or quick attendance summaries.

Finally, we believe the platform could benefit from a broader accessibility and identity pass. The existing use of both color and emoji for category distinction was a good step toward more inclusive design, and this could be extended with stronger keyboard support, screen-reader-aware labeling, reduced-motion considerations, contrast auditing, and list-first alternatives for map-heavy views. In parallel, the community dimension of profiles could be deepened through lightweight identity signals such as interest tags, short social bio prompts, and clearer “attends/hosts” style summaries.

5. Individual Contributions

Team Member Subgroup Individual Contribution Page
Buğra Keser Mobile Final Milestone Individual Contribution: Buğra Keser
Sevde Pekköse Mobile Final Milestone Individual Contribution: Sevde Pekköse
Oğuz Özer Frontend Final Milestone Individual Contribution: Oğuz Özer
Mehmet Akif Yıldırım Backend Final Milestone Individual Contribution: Mehmet Akif Yıldırım
Cansu Er Mobile Final Milestone Individual Contribution: Cansu Er
Emine Türk Frontend Final Milestone Individual Contribution: Emine Türk
Utku Yiğit Demir Backend Final Milestone Individual Contribution: Utku Yiğit Demir
Mehmet Kaan Ünsel Backend & DevOps Final Milestone Individual Contribution: Mehmet Kaan Ünsel

6. Final Software Release & Setup

👥 Team Members

Labs

Meetings

Milestones

Requirements & Analysis

Scenarios

Use Case Diagrams

Class Diagrams

Sequence Diagrams

Planning

Testing

MVP Demo Plan

Clone this wiki locally