Cereri Concediu
Aplicație web pentru cererile de concediu de odihnă într-o firmă cu mai multe puncte de lucru (de exemplu, un lanț de farmacii). Angajații își depun cererile online și văd cine din echipă lipsește. Fiecare cerere ajunge la administrator, care o aprobă sau o respinge, iar regulile firmei îi semnalează ce trebuie verificat. Zilele se acumulează și expiră după regulile din Codul muncii, iar fiecare cerere aprobată are un PDF gata de semnat.
In English: a leave-management web app for a Romanian company with several locations. Employees request leave online, every request goes to an admin for approval with rule warnings attached, leave balances accrue monthly and expire per the Romanian Labour Code, and every approved request gets a signable PDF. Built with Next.js 16, TypeScript, Prisma/PostgreSQL and NextAuth, with ~390 unit tests run in two time zones and CI.
Încearcă demo-ul → · intri cu un click, ca administrator sau ca angajat, pe date fictive.
Ce poate face
Angajatul
- Depune o cerere dintr-un calendar care marchează weekendurile, sărbătorile legale și colegii de la același punct de lucru aflați în concediu.
- Vede înainte de trimitere câte zile lucrătoare are cererea, soldul rămas, ce reguli încalcă, dacă încalcă vreuna, și care colegi de la același punct de lucru au deja concediu aprobat în acele zile.
- Își urmărește cererile, le poate anula pe cele în așteptare și concediile aprobate care nu au început (zilele revin în sold), și descarcă PDF-ul cererilor aprobate.
- E avertizat pe panou dacă are zile neplanificate care expiră la următorul termen (30 iunie) și până când trebuie să le ia.
- Își resetează singur parola prin email.
Administratorul
- Panou cu ce cere atenție: cereri în așteptare, cine e în concediu azi, plecări în următoarele 14 zile, angajați cu sold mic și angajații cu zile care urmează să expire.
- Aprobă sau respinge cereri, cu motiv, filtrate după status, punct de lucru și angajat. Vede soldul angajatului înainte și după aprobare și trebuie să confirme explicit o aprobare care l-ar face negativ. La fiecare cerere în așteptare vede câți colegi de la același punct de lucru lipsesc în acea perioadă, cu numele și zilele lor. Poate anula un concediu aprobat care nu a început.
- Gestionează angajații: date, sold inițial, ajustări de sold cu motiv și an, resetare de parolă, dezactivare.
- Configurează reguli fără cod: preaviz minim, lună restricționată (ex. inventar), concediu neîntrerupt anual de minim 10 zile (art. 148).
- Exportă situația zilelor în Excel și vede jurnalul complet al acțiunilor.
Automat
- Acumulare lunară de zile (cron Vercel). O lună ratată (rulare eșuată sau oprită) se recuperează la următoarea rulare, fără lunile în care contul era dezactivat.
- Expirarea zilelor neefectuate după 18 luni (art. 146 alin. 2), pe principiul primul intrat, primul ieșit (FIFO), cu recuperarea anilor ratați.
- Emailuri pentru cereri noi (către administratori), aprobări și respingeri.
- Pe instanța demo, datele se refac în fiecare noapte: ce schimbă vizitatorii dispare, iar perioadele sunt din nou relative la ziua de azi.
Decizii tehnice
- Zilele calendaristice sunt
Date la miezul nopții UTC (lib/dates.ts), exact ce scrie Prisma într-o coloană @db.Date. Browserul trimite yyyy-MM-dd, iar „azi” se calculează în ora României. Așa rezultatele sunt aceleași pe serverul Vercel (UTC) și pe un laptop din București; testele rulează în ambele fusuri orare.
- Sărbătorile legale din România se calculează, nu se scriu de mână: Paștele ortodox (algoritmul Gauss), Rusaliile, plus 6–7 ianuarie începând cu 2024 (Legea 37/2024).
- Nicio cerere nu se aprobă automat, iar regulile nu resping, ci atenționează: o cerere care încalcă o regulă (sau depășește soldul, socotind și cererile încă în așteptare) ajunge la administrator cu motivul explicit. Doar suprapunerea cu o cerere proprie, o dată în trecut sau lipsa zilelor lucrătoare blochează trimiterea. Previzualizarea și crearea folosesc aceeași funcție de validare.
- Colegii absenți se numără pe oameni, nu pe cereri, și nu blochează nimic (
lib/leaves/colleague-absences.ts): un coleg cu două concedii în aceeași perioadă apare o singură dată. Lista se calculează la afișare, nu se salvează la depunere, deci o aprobare sau o anulare de mai târziu se vede imediat. Angajatul vede doar concediile aprobate ale colegilor (ca în calendar); adminul vede și cererile lor încă în așteptare.
- Avertizarea despre zilele care expiră folosește exact calculul expirării (
planRollover), rulat în avans: angajatul vede ce se va întâmpla efectiv pe 1 iulie, nu o estimare. Jurisprudența CJUE (C-619/16, C-684/16) cere ca angajatul să fie informat din timp înainte ca zilele să se piardă.
- Ajustările de sold au un an: zilele adăugate aparțin unui an și expiră odată cu el (art. 146). O scădere se face dintr-un an anume, cel mult cât a câștigat angajatul în acel an, sau din cele mai vechi zile, ca un concediu.
- Operațiile pe sold sunt atomice: crearea, aprobarea, anularea și ajustarea blochează rândul angajatului (
SELECT … FOR UPDATE), iar tranzițiile de status sunt condiționate de statusul curent, ca un dublu click să nu scadă zilele de două ori. Cron-urile sunt idempotente.
- Securitate:
- rolul și starea contului se reîncarcă periodic din baza de date, deci un cont dezactivat își pierde accesul în câteva minute;
- schimbarea sau resetarea parolei închide toate sesiunile deschise ale contului (
sessionVersion);
- rate limiting la login și la schimbarea parolei, pe utilizator + IP, cu Upstash Redis, iar login-ul durează la fel cu sau fără cont existent;
- tokenurile de resetare se stochează doar ca hash, sunt de unică folosință și expiră într-o oră; răspunsul e același pentru orice utilizator, ca să nu se poată afla ce conturi există;
Stack
Next.js 16 (App Router), React 19, TypeScript, Tailwind CSS 4 + shadcn/ui (Base UI), Prisma 6 + PostgreSQL (Supabase), NextAuth.js, Resend + React Email, @react-pdf/renderer, ExcelJS, Vitest, GitHub Actions, Vercel (inclusiv cron-urile).
Structură
app/(employee) paginile angajatului: panou, cerere nouă, cereri, profil
app/(admin)/admin administrare: panou, cereri, utilizatori, puncte de lucru, reguli, rapoarte, jurnal
app/(auth) login, schimbare și resetare parolă
app/api rutele API (cereri, administrare, resetare parolă, cron)
lib/constraints motorul de reguli (validateLeaveRequest)
lib/leaves acumulare, expirare (rollover) și statistici
lib/dates.ts convenția pentru zile calendaristice
lib/holidays.ts sărbătorile legale și zilele lucrătoare
lib/pdf, lib/emails documentul cererii și emailurile
prisma/ schema, migrările și scripturile (seed, demo, reparații)
tests/ testele Vitest
Rulare locală
Ai nevoie de Node.js 20.19+ și de o bază PostgreSQL (locală sau Supabase).
npm install
cp .env.example .env.local # completează DATABASE_URL, DIRECT_URL, NEXTAUTH_SECRET
npx prisma migrate deploy
npm run db:seed # creează administratorul din ADMIN_USERNAME / ADMIN_PASSWORD
npm run dev
Pentru date de test realiste, pe o bază separată:
# bash / macOS / Linux
DEMO_MODE=true NEXT_PUBLIC_DEMO_MODE=true npm run db:seed-demo # ȘTERGE baza
# Windows (PowerShell)
$env:DEMO_MODE = "true"; $env:NEXT_PUBLIC_DEMO_MODE = "true"; npm run db:seed-demo # ȘTERGE baza
Variabilele pot fi puse și în .env.local (DEMO_MODE=true, NEXT_PUBLIC_DEMO_MODE=true), care funcționează la fel pe orice sistem.
Scriptul creează 3 puncte de lucru, 10 angajați și cereri în toate stările. Cu NEXT_PUBLIC_DEMO_MODE=true, pagina de login afișează butoanele „Intră ca administrator” și „Intră ca angajat” (admin.demo / angajat.demo, parola Demo2026!). În modul demo, conturile demo nu pot fi dezactivate, parola lor nu poate fi schimbată și nu se trimite niciun email.
| Comandă | Ce face |
|---|
npm run dev | server de dezvoltare |
npm test | testele Vitest, în UTC și în ora României |
npm run lint | ESLint |
npm run build | build de producție |
npm run db:seed-demo | date demo (doar cu DEMO_MODE=true) |
npm run db:reset-password -- <utilizator> <parolă> | resetează parola unui cont (cere schimbarea ei la logare) |
npm run db:create-employee -- <utilizator> <parolă> | creează rapid un angajat de test |
npm run db:fix-leave-dates -- --before=<ISO> | repară cererile vechi salvate cu o zi mai devreme (fără --apply doar afișează) |
Deploy
Pe Vercel, cu PostgreSQL pe Supabase:
- Setează în Vercel variabilele din
.env.example. Obligatorii: DATABASE_URL (pooler, port 6543, ?pgbouncer=true), DIRECT_URL (port 5432), NEXTAUTH_SECRET, NEXTAUTH_URL și CRON_SECRET (minim 16 caractere). Opționale: RESEND_API_KEY și EMAIL_FROM pentru emailuri, Supabase Storage pentru arhivarea PDF-urilor, Upstash Redis pentru rate limiting comun.
- Rulează migrările pe baza de producție:
npx prisma migrate deploy.
- Cron-urile din
vercel.json rulează acumularea lunară (pe 1 ale lunii), expirarea anuală (pe 1 iulie) și, doar pe instanța demo, refacerea datelor demo (în fiecare noapte, la 01:00 UTC).
Fără Vercel (de exemplu pe un PC din firmă, cu npm run build și npm start), cron-urile din vercel.json nu rulează singure. Programează din Windows Task Scheduler (sau cron) câte o cerere GET cu antetul Authorization: Bearer <CRON_SECRET> către /api/cron/monthly-accrual pe 1 ale lunii și către /api/cron/yearly-rollover pe 1 iulie. Ambele sunt idempotente, deci o rulare repetată nu adaugă și nu scade zile de două ori.
O instanță demo publică are nevoie de un proiect Vercel separat, cu propria bază de date, DEMO_MODE=true și NEXT_PUBLIC_DEMO_MODE=true. Acolo, /api/cron/demo-reset șterge baza în fiecare noapte și pune la loc datele fictive (ca npm run db:seed-demo), într-o singură tranzacție: dacă ceva eșuează, rămân datele din ziua precedentă. Pe o instanță fără DEMO_MODE=true același cron nu atinge nimic.
CI-ul (.github/workflows/ci.yml) rulează la fiecare push lint-ul, verificarea de tipuri, testele în ambele fusuri orare și build-ul. Separat, aplică migrările pe un Postgres 16 și verifică dacă schema s-a îndepărtat de migrări.
Autor
Astefanei Razvan · LinkedIn · GitHub
Dezvoltat cu Claude Code ca asistent de programare. Deciziile de produs, regulile de business și testarea îmi aparțin.
