What's new
at Xicar

Administrative driver rating and ride-service restriction controls are now available in the admin codebase, with the corresponding ride-hailing backend support still under review.

Driver ratings and service-level restrictions

The admin interface now shows driver ratings by ride service, including rating source and author attribution, and allows administrators to add ratings tied to either Xiclo two-wheel service or Xicar four-wheel service.

Administrators can also restrict a driver from a specific ride service without disabling the driver’s access to the other service. Restrictions can record a reason and optional supporting rating, and the admin interface supports reinstatement plus review of driver appeals.

Trusted Cloudflare Access identity is forwarded to the backend for these actions so administrative ratings and restriction decisions can be attributed to the authenticated administrator.

Backend enforcement in review

The matching ride-hailing backend changes are currently in PR #10 and have not yet been merged into beta. The proposed backend work adds rating metadata and migration support, service-specific restriction records, driver appeal handling, and enforcement when drivers go online, receive offers, or attempt to accept bookings.

Until that backend PR is merged and deployed, the newly merged admin controls should be treated as interface support for functionality that is not yet fully delivered end to end.

References

• Admin driver rating and restriction controls (admin mirror PR #3)
• Ride ratings and service restrictions backend (ride-hailing mirror PR #10)

This update brings tighter attendant access controls together with a smoother admin experience for managing day-to-day operations.

Attendant access and registration

Attendant registration now supports explicit pending, active, inactive, and archived account states. New attendants remain in an approval-pending flow until an administrator grants access, while disabled or archived attendants are prevented from continuing service operations.

The attendant app also rechecks account access while it is in use, so administrative changes can take effect without relying on a fresh sign-in. On the backend, duplicate phone checks are normalized, administrative attendant actions are HMAC-protected, and archived attendants retain their historical booking records.

Attendant booking and dashboard workflows

Attendant-created bookings now remain available for matching instead of being automatically cancelled when the normal driver retry budget is exhausted. The app surfaces driver acceptance notifications, keeps active booking status synchronized through WebSocket updates and targeted REST reconciliation, and shows a single completion or cancellation result even when duplicate lifecycle updates arrive.

The attendant home screen now uses a compact dashboard feed for pending, accepted, and trip-started booking counts plus online-driver availability. Booking history shows customer details while withholding assigned-driver information until acceptance, and booking cards expose the booking ID so attendants can match notifications to the correct trip.

Shared WebSocket subscriptions now track ownership per screen, preventing one screen from accidentally disconnecting another screen that is watching the same booking. The backend also batches online-driver session reads to reduce repeated Redis round trips during the dashboard’s periodic refresh.

Admin attendant management

The admin interface now supports editing attendant profiles, enabling or disabling access, archiving accounts, and restoring archived attendants. Booking filters can load the complete attendant list, including archived attendants where historical records need to remain identifiable.

Admin data views also gain clearer loading states, debounced search behavior, client-side sidebar navigation that preserves scroll position, and skeleton placeholders across major dashboard screens.

Scheduling, notifications, and exports

Notification schedules can now be edited, cancelled, and deleted with stronger schedule timing and app validation. Delivery failures are reported with partial fan-out retry details, while status refreshes provide clearer feedback.

Admin date and time rendering is standardized on Manila time, list searches are normalized and debounced, and full booking PDF exports now expose progress and can be cancelled. The admin Docker Compose default database is also updated to xicaradmin.

References

• Attendant registration and access management (ride-hailing mirror PR #7)
• Attendant booking acceptance and dashboard workflows (ride-hailing mirror PR #8)
• Improve admin loading and attendant management (admin mirror PR #1)
• Improve notification schedules and admin workflows (admin mirror PR #2)

Xicar now has one place to follow meaningful product and operational changes.

Each update pairs what changed with why it matters, giving the team a shared, business-friendly record of progress without losing the technical details needed for traceability.

Infrastructure

Hugo-powered changelog site

The changelog site now runs on Hugo instead of the custom Python static-site generator. The existing design remains intact, while daily Markdown files, automatic date ordering, month grouping, and the static public/ output make ongoing publishing simpler and more consistent.

The migration also adds Hugo-based smoke checks pinned to version 0.147.7, preserving the site’s JavaScript-free output and validation of links, dates, headings, and security-sensitive content. Cloudflare Pages preview validation passed; production deployment status is not separately verified here.

References

• Launch the changelog (PR #1)
• Replace the Python changelog builder with Hugo (PR #5)
• Merge commit 0d13f2b