Rogo Portal

Rogo Portal is organized around the student file. It links a user to education format, education level, academic session, program, target universities, documents, services, timeline entries, and transactions.

Creating a student file is a multi-step intake flow: email lookup, personal and passport information, admission details, payment information, and services. The backend creates the file, university links, scheduled payments, and selected services inside a database transaction.

Passport data uses an upsert-style update tied to the student user, which lets staff update information without creating duplicate passport records.

The student-file table supports search by student name, filters for academic session and education level, sorting by name, creation date, or payment due, and a payment-due range filter.

A student detail page brings contact information, admission information, process timeline, service package, checklist, documents, payment summary, and payment records into one view.

Timeline entries can include status, university, description, and supporting documents. Checklists track required tasks with due dates and completion state. Service packages show which consultancy services are included and whether they have been provided.

Staff can upload typed documents, attach files to timeline updates, mark documents visible to the student, and update or delete records from the dashboard.

UploadThing handles uploads. The database stores document type, name, owner, student file, timeline linkage, URL, and visibility state. Students only see documents tied to their file and marked visible.

Better Auth roles separate admin, admission officer, support manager, and student access. Protected tRPC procedures enforce authentication, and resource permissions guard actions such as managing documents, checklists, and transactions.

Admissions teams need to see the expected payment, paid amount, scheduled installments, pending approval records, and remaining due balance.

Rogo Portal models payment records as transactions with status and type. SQL queries calculate payment due, total income, total expense, and gross profit from those records.

The payment record view supports status tabs, search, scheduled payments, paid records, and editable transaction details, so staff can follow up on installments without leaving the student file.

The interface follows the daily work of admissions staff. The create flow breaks intake into clear steps, and the detail page groups the information staff revisit often.

React Hook Form and Zod keep form behavior predictable across intake, document forms, timeline updates, service entries, and payment records. tRPC and TanStack Query connect the UI to typed server procedures and update cached data after mutations.

The product also has role-based entry points. Admins see the operations dashboard, while student users get a simpler view of upcoming sessions, checklists, pending submissions, and payments.