Technical TODO
Pending technical tasks and investigations that are not yet committed to a sprint but should be tracked.
[TODO-001] Investigate and Fix GraphQL AppConfigurations Query
- Priority: Medium
- Type: Bug Investigation
- Created: 2026-05-30
- Bounded Context: Configuration
- Status: Open
Problem
GraphQL endpoint /graphql for appConfigurations query returns empty results (items: [], totalItems: 0) while the REST-backed configuration reads return correct data.
Observations
- Handler executes successfully in ~25ms (no errors)
- REST API works correctly with identical query parameters
- Other GraphQL queries (e.g.,
tenants) work correctly
- AppConfigurationDto type exists in GraphQL schema
- Issue is specific to AppConfiguration bounded context
Affected Files
src/apps/ums.api/Ums.Presentation/GraphQL/Configuration/AppConfigurationQueries.cs
src/apps/ums.api/Ums.Application/Configuration/AppConfiguration/Queries/GetAllAppConfigurationsQueryHandler.cs
src/apps/ums.api/Ums.Presentation/Middleware/TenantContextMiddleware.cs
src/apps/ums.api/Ums.Presentation/Middleware/DevAuthMiddleware.cs
Workaround
Use the REST configuration read path for AppConfigurations in the frontend. GraphQL for this bounded context remains unresolved in the backend resolver.
Next Steps
- Add debug logging to HotChocolate resolver execution
- Compare GraphQL vs REST request pipeline differences
- Investigate DataLoader caching issues
- Check if there’s a resolver scope mismatch
[TODO-002] Remove GraphQL Code Path from AppConfiguration Service
- Priority: Low
- Type: Code Cleanup
- Created: 2026-05-30
- Bounded Context: Configuration (Frontend)
- Status: Completed
Problem
The frontend app-configuration.service.ts previously contained dual-transport logic (GraphQL + REST) even though the service had already standardized on REST. The GraphQL code path was dead code.
Affected Files
src/apps/ums.web-app/src/infrastructure/configuration/services/app-configuration.service.ts
Resolution
The service now uses REST exclusively, and the stale GraphQL path has been removed from the frontend codebase.
Next Steps
No further action required.
[TODO-003] Implement Parameterization System with Loader and Provider
- Priority: High
- Type: Architecture / Feature Implementation
- Created: 2026-05-30
- Bounded Context: Configuration
- Status: In Progress
Problem
Currently, configurable behaviors in UMS may be hardcoded in web, API, services, or components. A centralized parameterization system is required to store all configurations in the database, load them into memory at startup, and provide a single access point for all system logic.
Specification
See: Parameterization System Specification
Affected Areas
- Backend: New ConfigurationLoader and ConfigurationProvider services
- Frontend: Tenant configuration tab in Tenant dashboard
- Database: ScopeId support for Global (1) and Tenant (2) parameters
- API: New endpoints for global and tenant-specific configurations
Implemented Components (Phase 1)
Backend
- ConfigurationBootstrapper (
Ums.Presentation/Bootstrapping/Bootstrappers/ConfigurationBootstrapper.cs)
- Bootstrapper pattern for synchronous initialization at startup
- Loads parameters BEFORE other services resolve IConfigurationProvider
- Uses CompositeBootstrapper to ensure proper ordering
- ConfigurationProvider (
Ums.Infrastructure/Configuration/ConfigurationProvider.cs)
- Single access point for all configuration values
- Implements precedence logic (Tenant > Global when allowed)
- In-memory ConcurrentDictionary cache for global and tenant parameters
- Provides ReloadAsync and ReloadTenantAsync methods
- ConfigurationChanged event for audit integration
- IConfigurationProvider (
Ums.Application/Configuration/Services/IConfigurationProvider.cs)
- Interface defining GetGlobal, GetForTenant, GetWithPrecedence
- GetValueAs for typed parameter retrieval
- Event-based change notification
- ConfigurationAuditService (
Ums.Application/Configuration/Services/ConfigurationAuditService.cs)
- Audit trail integration for parameter changes
- ConfigurationLoaderExtensions (
Ums.Infrastructure/Configuration/ConfigurationLoader.cs)
- Extension method for DI registration of IConfigurationProvider
- ConfigurationValues (
Ums.Application/Configuration/Services/ConfigurationValues.cs)
- Typed wrapper for common configuration values
- Provides strongly-typed access to: SessionTimeout, MaxLoginAttempts, MinPasswordLength, etc.
- Supports tenant-specific overrides with precedence logic
- Configuration consumers already wired
AddUserAccountPasswordCommandValidator reads MIN_PASSWORD_LENGTH through ConfigurationValues
AuthEndpoints resolves login session parameters through the typed wrapper
- Tenant-Specific Parameters Seeded
- RANSA_PERU: SESSION_TIMEOUT=45min, MFA_REQUIRED=true, CUSTOM_BRANDING=true
- APM_CALLAO: SESSION_TIMEOUT=20min, MAX_LOGIN_ATTEMPTS=3, MFA_REQUIRED=true
- NEPTUNIA: SESSION_TIMEOUT=60min, MIN_PASSWORD_LENGTH=14
Frontend
- TenantConfigurationsPanel (
presentation/identity/tenant/components/TenantConfigurationsPanel.tsx)
- Tab in TenantDetailPanel for tenant-specific parameters
- View/edit tenant parameters
- Add new tenant parameters
- Visual indication of override vs global parameters
- Updated TenantDetailPanel
- Integrated TenantConfigurationsPanel in the ‘configurations’ tab
- New Translations Added
- Configuration parameter UI strings (EN/ES)
Remaining Work
- Add Redis migration preparation (TD-003)
- Expand
ConfigurationValues consumers to any remaining handlers or validators as new parameterized behaviors are added
- Add parameter-level authorization where future policies require it
[TODO-004] Create Global Configuration Admin Screen
- Priority: High
- Type: Feature Implementation
- Created: 2026-05-30
- Bounded Context: Configuration
- Status: Completed
Problem
Internal Admin needs a dedicated screen to view and manage system-wide (Global) parameters separate from tenant-specific parameters.
Requirements
- Admin-only access (Internal Admin role required)
- List all global parameters (ScopeId = 1)
- View parameter details (code, value, description, status, version)
- Edit global parameter values
- Create new global parameters
- View audit history for parameter changes
Affected Areas
- Frontend: New
/app-configurations/global route
- Backend: Global configuration API endpoints
- UI: Standalone configuration management screen (not in tenant context)
Resolution
- The global screen now exists at
/app-configurations/global.
- Access is restricted to internal admins in the frontend, while the backend still enforces the same rule at the endpoint layer.
- The detail panel includes audit history backed by the REST
/audit-records endpoint.
Next Steps
No further action required.