RBAC Improvements
Caching improvements Maker-Checker Implementation
This commit is contained in:
@@ -8,14 +8,16 @@ An enterprise system designed to manage the entire post-funding grant and projec
|
||||
|
||||
The application follows a modular, hierarchical architecture where high-level funding directives cascade into measurable project outcomes and evidence verification.
|
||||
|
||||
```text
|
||||
[Portfolios] ───> [Programmes] ───> [Projects] ───> [Awards] ───> [Contracts] ───> [Beneficiaries] ──> [Outcomes]
|
||||
│ │ │
|
||||
▼ │ ▼
|
||||
[Rules] ├─> [Milestones] ──> [Activities] ──> [Evidences]
|
||||
├─> [Disbursements]
|
||||
├─> [Indicators]
|
||||
├─> [Risks] & [Issues]
|
||||
└─> [SiteVisits] & [ComplianceItems]
|
||||
├─> [Disbursements]
|
||||
├─> [Indicators]
|
||||
├─> [Risks] & [Issues]
|
||||
└─> [SiteVisits] & [ComplianceItems]
|
||||
```
|
||||
|
||||
### **1. Portfolio & Programme Governance**
|
||||
* **Portfolios**: Top-level containers for strategic investment themes.
|
||||
@@ -55,45 +57,85 @@ The application follows a modular, hierarchical architecture where high-level fu
|
||||
|
||||
## 🛠️ Tech Stack & Patterns
|
||||
|
||||
* **Backend Framework**: .NET 8 / 9 C# Web API
|
||||
* **Database**: PostgreSQL
|
||||
* **ORM**: Entity Framework Core (Fluent API Configuration)
|
||||
* **Architecture**: Clean Architecture / Domain-Driven Design (DDD) with CQRS (`MediatR`)
|
||||
* **Utilities**: `Humanizer` (Automated entity-to-table pluralization)
|
||||
* **Backend Framework**: .NET 10.0 (C# 13) Web API / Minimal APIs
|
||||
* **Frontend Portals**:
|
||||
* `PostFundManagement.ConsoleUI`: Internal Staff & Portfolio Administration Portal (React 19 + TypeScript + Vite + Tailwind CSS)
|
||||
* `PostFundManagement.PartnerUI`: External Recipient & Grantee Portal (React 19 + TypeScript + Vite + WebGL OGL)
|
||||
* **Database**: PostgreSQL 14+ with Npgsql & EF Core 10
|
||||
* **Security & Authentication**: Duende IdentityServer / OIDC PKCE + Claim-Based RBAC
|
||||
* **Governance Patterns**: Maker-Checker Pattern (Dual Authorization & Segregation of Duties)
|
||||
* **Architecture**: Clean Architecture / Domain-Driven Design (DDD) with CQRS (`Mediator`)
|
||||
* **Object Storage**: S3-compatible storage (Garage S3 / AWS S3)
|
||||
* **Caching & OutputCache Invalidation**: Redis StackExchange + ASP.NET Core `OutputCaching` (2-minute base policy) coupled with TanStack Query v5 and Axios client-side mutation versioning (`_v` parameter) for instantaneous reads and guaranteed zero-staleness on mutations
|
||||
* **Telemetry**: OpenTelemetry Metrics, Traces & Logs with Aspire / OTLP
|
||||
|
||||
---
|
||||
|
||||
## 🔒 Role-Based Access Control (RBAC) & Maker-Checker Pattern
|
||||
|
||||
The platform implements strict governance invariants across all operational domains:
|
||||
|
||||
### 1. Progressive Action Hierarchy
|
||||
* **`view`**: Read-only inspection of entity lists, details, and metrics.
|
||||
* **`add`**: Create new records, edit drafts, submit evidence, and adjust non-approval statuses.
|
||||
* **`update`**: Authoritative record **approval** authority (`Approved`, `Active` contracts).
|
||||
* **`export`**: Export tabular data and reports (`.xlsx`, `.pdf`).
|
||||
* **`all`**: Comprehensive authority across the claim domain.
|
||||
|
||||
### 2. Role Claim Matrix
|
||||
* **`Admin`**: `unrestricted: all` — Full system-wide administration.
|
||||
* **`Executive`**: Strategic oversight across Dashboard, Governance, Projects, Grants, M&E (`all`).
|
||||
* **`Manager`**: Comprehensive operational control across all domains (`all`).
|
||||
* **`Supervisor`**: Operational oversight and verification (`view, add, update, export`).
|
||||
* **`Contributor`**: Working-level execution (`view, add`). Strictly barred from record approvals and exports.
|
||||
* **`Partner`**: External recipient. Confined strictly to `PartnerUI`; locked out of `ConsoleUI`.
|
||||
|
||||
### 3. Maker-Checker Segregation of Duties
|
||||
To eliminate conflicts of interest, record creators ("Makers") cannot approve ("Check") their own records. Even if an officer possesses the `update` claim, the system dynamically blocks self-approval on any record matching their `createdBy` identifier:
|
||||
$$\text{Can Approve} = \text{Has 'update' permission} \land (\text{Current User ID} \neq \text{Record Creator ID})$$
|
||||
|
||||
For in-depth architectural and operational specifications, see:
|
||||
* [Architecture.md](file:///c:/Users/Admin/source/repos/PostFundManagement/Architecture.md)
|
||||
* [Processes.md](file:///c:/Users/Admin/source/repos/PostFundManagement/Processes.md)
|
||||
* [GEMINI.md](file:///c:/Users/Admin/source/repos/PostFundManagement/GEMINI.md)
|
||||
|
||||
---
|
||||
|
||||
## 📁 Solution Structure
|
||||
|
||||
```text
|
||||
src/
|
||||
├── PostFundManagement.Domain/ # Core Domain Entities, Enums & Interfaces
|
||||
├── PostFundManagement.Infrastructure/ # EF Core Configurations, DbContext, Migrations
|
||||
├── PostFundManagement.Application/ # CQRS Handlers, DTOs, Business Rules & Logic
|
||||
└── PostFundManagement.Api/ # REST Controllers, Middleware, Auth & Swagger
|
||||
PostFundManagement/
|
||||
├── PostFundManagement.Domain/ # Core Domain Entities, Enums & Interfaces
|
||||
├── PostFundManagement.Infrastructure/ # EF Core 10, PostgreSQL, Skoruba STS, Migrations
|
||||
├── PostFundManagement.Application/ # CQRS Handlers, DTOs, Business Rules & Validations
|
||||
├── PostFundManagement.Api/ # REST Endpoints, Middleware, Auth & Swagger/Scalar
|
||||
├── PostFundManagement.Tests/ # Unit & Integration Test Suite
|
||||
├── PostFundManagement.ConsoleUI/ # Internal Staff & Admin Web Portal (React 19 + Vite)
|
||||
├── PostFundManagement.PartnerUI/ # External Grantee / Recipient Portal (React 19 + Vite)
|
||||
├── Architecture.md # System Architecture, RBAC & Maker-Checker Spec
|
||||
├── Processes.md # Operational Grant Lifecycle & Process Flows
|
||||
└── docker-compose.yml # Container orchestration
|
||||
```
|
||||
|
||||
## 🚀 Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
.NET 8.0 SDK or higher
|
||||
PostgreSQL 14+
|
||||
dotnet-ef CLI Tool (dotnet tool install --global dotnet-ef)
|
||||
* .NET 10.0 SDK or higher
|
||||
* Node.js 20+ & Yarn (`yarn.lock` authoritative)
|
||||
* PostgreSQL 14+
|
||||
|
||||
## Setup & Execution
|
||||
|
||||
## Clone Repository
|
||||
|
||||
1. Clone Repository:
|
||||
### 1. Clone Repository:
|
||||
|
||||
```bash
|
||||
git clone [https://github.com/your-org/PostFundManagement.git](https://github.com/your-org/PostFundManagement.git)
|
||||
git clone https://github.com/your-org/PostFundManagement.git
|
||||
cd PostFundManagement
|
||||
```
|
||||
|
||||
2. Configure Database Connection:
|
||||
Update appsettings.Development.json in the API project with your local PostgreSQL details:
|
||||
### 2. Configure Database Connection:
|
||||
Update `appsettings.Development.json` in the API project with your local PostgreSQL details:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -103,16 +145,18 @@ Update appsettings.Development.json in the API project with your local PostgreSQ
|
||||
}
|
||||
```
|
||||
|
||||
3. Apply Database Migrations:
|
||||
### 3. Launch Backend API:
|
||||
|
||||
```bash
|
||||
dotnet ef database update --project src/PostFundManagement.Infrastructure
|
||||
dotnet run --project PostFundManagement.Api
|
||||
```
|
||||
|
||||
4. Launch Application:
|
||||
### 4. Launch ConsoleUI Frontend:
|
||||
|
||||
```bash
|
||||
dotnet run --project src/PostFundManagement.Api
|
||||
cd PostFundManagement.ConsoleUI
|
||||
yarn install
|
||||
yarn dev
|
||||
```
|
||||
|
||||
## 📄 License
|
||||
|
||||
Reference in New Issue
Block a user