🐛 Bugfix: The backend-vitto-api had a local roles.guard.ts with flat s...

Date: 2026-03-12
Time: 18:11:42 UTC
Session: gspace1-209.4
Agent: backend
Confidence: 96%
Status: ✅ Documented

📋 Decision Context

Question:

The backend-vitto-api had a local roles.guard.ts with flat string matching (no hierarchy). Should it be replaced?

Task: Fix Vitto API local roles guard to use hierarchy

🎯 Decision Made

Chosen:

Replace the local guard file with a re-export from @libs-api/auth-core. The file now contains only: export { RolesGuard, Roles, SystemRoles } from '@libs-api/auth-core'. This preserves backward compatibility for security.controller.ts while using the hierarchy-aware guard.

Options Considered:

1. Re-export from @libs-api/auth-core (chosen — minimal change, fixes behavior)
2. Update security.controller.ts import to @libs-api/auth-core directly (works but unnecessary churn)
3. Copy the hierarchy logic into the local file (violates DRY)

💭 Reasoning

The local RolesGuard in backend-vitto-api/auth/roles.guard.ts used flat string matching (requiredRoles.some(role => userRoles.includes(role))) with no hierarchy awareness. This meant @Roles('admin') would NOT pass for an executive user — they'd need to be explicitly listed. The shared guard in @libs-api/auth-core has a ROLE_HIERARCHY map where executive(90) automatically satisfies admin(60) checks. Only one consumer used the local guard (security.controller.ts), and the main vitto.controller.ts already imported from @libs-api/auth-core. Re-exporting avoids changing security.controller.ts imports while fixing the behavior.

📁 Files Involved

• APIs/backend-vitto-api/src/app/auth/roles.guard.ts
• APIs/backend-vitto-api/src/app/security/security.controller.ts

🔗 Related

• Decision ID: dev_1773339102249_nxwkony
• Session: 209
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation