Backend:
- Added TECHNICAL and SALES roles to UserRole enum
- Added TicketDepartment, TicketStatus, TicketPriority enums
- Created Ticket and TicketMessage entities with relationships
- Created TicketsModule with full CRUD service and controller
- Ticket routing: users create tickets to technical/sales departments
- Staff reply updates status (answered), user reply sets waiting
- Role-based access: technical staff sees technical tickets, sales sees sales tickets
- Admin sees all tickets with stats (total, open, avg response time)
- Updated access control: technical role has admin-level access (except role change)
- Sales role can view users and handle sales tickets
- Clusters controller: technical role can manage clusters/pools
- Users controller: technical/sales can view users, only admin changes roles
Frontend:
- New user ticket pages: list (with create form) + detail (chat-style messages)
- Staff ticket panel: filtered by department with status filters
- Admin all-tickets page with statistics dashboard and department/status filters
- Updated sidebar: role-based nav items (admin/technical/sales sections)
- Role badges in header for technical (blue) and sales (green)
- Admin users page: new roles in dropdowns, role change restricted to admin only
- Deploy page: technical role gets cluster selection access like admin
Backend:
- ApplicationsService.create() now accepts userRole parameter
- Non-admin users have clusterId/poolId stripped automatically
- Logs warning when non-admin attempts manual cluster selection
Frontend:
- Deploy wizard hides cluster assignment mode selector for non-admin users
- Non-admin users see a simple 'Default Cluster' info box instead
- Cluster/pool API queries only execute for admin users (enabled: isAdmin)
- Review step shows 'Default Cluster' for non-admin regardless of form state
Most user apps (e.g. Next.js) don't have a /health endpoint, causing
liveness/readiness probes to fail with 404 and crash-loop the pods.
TCP socket probes just check if the port is open, which works universally.
npm ci fails when package-lock.json is out of sync with package.json,
which is common with GitHub-downloaded ZIPs. Switched to npm install
with --legacy-peer-deps flag for maximum compatibility.
GitHub-downloaded ZIPs contain files inside a subfolder (e.g., repo-main/).
The build init container now detects this pattern and flattens the contents
to the workspace root so Kaniko can find package.json and other files.
- Add POST /users endpoint for admin to create users with hashed passwords
- Add GET /users?search= with ILike search on email/firstName/lastName
- Add PATCH /users/:id/role for role assignment (user/admin)
- Return appCount per user in the users list
- Add GET /clusters/:id/resources for node, CPU, memory, pod monitoring
- Parse K8s node capacity/allocatable with CPU millicores and memory MiB helpers
- Frontend: admin users page with search bar, create form, role dropdown, app count
- Frontend: cluster resource panel with nodes table, CPU/memory bars, summary cards
- Add ClusterPool entity for grouping clusters into named pools
- Support 3 deployment modes: manual cluster, pool load-balanced, default fallback
- Pool strategies: least-apps (fewest deployed apps) and round-robin
- Add pool CRUD API endpoints (admin) and public pool listing
- Frontend deploy page: 3-mode cluster selector (Default/Manual/Pool)
- Frontend app detail: shows assigned cluster and pool info
- Admin pools management page with cluster selection and strategy picker
- Application entity extended with poolId field
- Backend: getPreviewInfo() in KubernetesService auto-patches ClusterIP
service to NodePort for direct external access
- Backend: GET /applications/:id/preview endpoint returns access URL
with nodePort, host IP (extracted from kubeconfig), and ingress URL
- Frontend: '🌐 Preview' button on app detail page (visible when running)
opens the deployed app in a new browser tab via NodePort URL
- Tested: service patched to NodePort 30107 successfully
- Backend: getResourceUsage() method in KubernetesService fetches real-time
CPU/Memory metrics from K8s metrics-server API per pod
- Backend: updateResources() method patches live K8s deployments with new
CPU/Memory requests+limits and replica count
- Backend: GET /applications/:id/resources endpoint for monitoring
- Backend: PATCH /applications/:id/resources endpoint for scaling
- Backend: ScaleResourcesDto with validation for resource fields
- Frontend: Resource monitoring card with per-pod CPU/Memory progress bars
(color-coded: green < 50%, yellow < 80%, red > 80%)
- Frontend: Pod status table showing phase, readiness, restarts
- Frontend: Scaling controls for CPU request/limit, memory request/limit,
and replicas with +/- buttons
- Frontend: Auto-refresh metrics every 5 seconds when monitoring is open
- Frontend: parseCpuToMillicores/parseMemoryToMi helpers for metric parsing
- Backend: added redeployApplication() to DeploymentsService that creates
a new deployment record and re-runs the full build+deploy pipeline
- Backend: added POST /deployments/applications/:appId/redeploy endpoint
- Frontend: added Redeploy button on app detail page, visible after first
deploy when no build is in progress
- For git-based apps: pulls latest code from repo on each redeploy
- For zip-based apps: rebuilds from last uploaded source code
keyhan