Implement PayRuleSet and BreakPolicy with nested entity persistence

[Copilot]

Summary

Implements complete CRUD operations for PayRuleSet and BreakPolicy modules with nested entity persistence. Both modules support creating, updating, and deleting nested rules while maintaining database schema alignment.

Schema Alignment

PayRuleSet

• Changed day representation: dayOfWeek: number → dayCode: string (SUNDAY, MONDAY, etc.)
• Changed tier structure: percentage-based → time-based (upToSeconds)
• Three-level hierarchy: PayRuleSet → PayDayRule → PayTierRule

BreakPolicy

• Changed duration fields: *Seconds → *Minutes to match database schema
• Two-level hierarchy: BreakPolicy → BreakPolicyRule
• Fields: dayOfWeek: number, paidBreakMinutes, unpaidBreakMinutes

JSON Deserialization

All model ID fields changed from int to int? to accept Angular's "id": null for new entities:

// Prevents deserialization failure when Angular sends null IDs
public int? Id { get; set; }

UpdateModels no longer include ID property - passed as URL parameter only:

// Service signature
updatePayRuleSet(id: number, model: PayRuleSetUpdateModel)
updateBreakPolicy(id: number, model: BreakPolicyUpdateModel)

Nested Entity Persistence

Services now handle complete nested entity lifecycle:

• Create: Creates parent + all nested entities in single transaction
• Update: Compares existing vs new, adds/updates/deletes nested entities
• Read: Loads complete hierarchy with eager loading

Controller Tests

Added JSON deserialization validation tests (8 tests total):

• Validates Angular JSON structure matches backend expectations
• Tests case-insensitive property mapping
• Confirms nullable IDs work correctly

TypeScript Alignment

Fixed property name consistency across models, services, and components:

• BreakPolicyModel.rules → breakPolicyRules (matches API response)
• All Create/Update models include nested rule arrays
• Form controls properly initialized for all fields

Files Modified

Backend (13 files)

• Models: PayDayRuleModel, PayTierRuleModel, BreakPolicyRuleModel, etc.
• Services: Complete nested entity handling
• Controllers: Clean API endpoints
• Tests: Comprehensive controller and service tests

Frontend (19 files)

• Models: Property name alignment with backend
• Services: Correct (id, model) signatures
• Components: Form controls for nested entities
• Templates: Day selectors, time-based inputs

Original prompt

---

This section details on the original issue you should resolve

<issue_title>🚀 Feature: Extend Rule Engine for Advanced Overtime & Holiday Logic (Non‑Breaking + API CRUD + Tests)</issue_title>
<issue_description>## 🎯 Goal

Implement advanced rule resolution logic using the updated database model without breaking any existing behavior.

This issue covers engine logic + API controllers/services + integration tests.
Database schema changes are handled separately.

Key principles (must-follow)

• ✅ Backward compatible: existing calculations and existing APIs must keep working as-is unless explicitly enabled via new configuration.
• ✅ Extend, don’t replace: build on existing rule engine code paths; gate new logic behind new rule fields / feature switches where needed.
• ✅ Incremental implementation: implement in small steps with green builds/tests after each step.
• ✅ No “big bang” refactors: avoid broad rewrites; prefer additive changes and well-scoped refactors.
• ✅ Safety checks before commit: run build + all tests before committing any changes.

---

🤖 GitHub Copilot Implementation Workflow (required)

0) Analyze first

Before writing code, Copilot must:

1. Locate current rule-engine calculation flow (entry points, services, calculators).
2. Identify existing overtime logic + holiday logic + day classification logic.
3. Identify where pay lines are generated (PlanRegistrationPayLines, existing pay code rules).
4. Identify existing API layer patterns (controllers/services/repositories), and existing integration test patterns.

1) Write a plan

Copilot must produce a short plan in the PR/commit message or as a comment in the issue describing:

• Which files/classes will be touched
• The order of implementation steps
• How backward compatibility is ensured (feature gating / defaults)
• Which tests will be added per step

2) Implement in steps (each step must be green)

For each step:

• Implement a small change
• Add/adjust tests for that change
• Run dotnet build and all tests
• Only then commit

---

🧮 Engine Implementation Tasks

1️⃣ Overtime Calculation (non-breaking)

Add support for:

• Weekly overtime
• Bi-weekly (14 days) overtime
• Monthly overtime
• Rolling averaging periods

Use new fields from WorkingTimeRuleSets:

• OvertimePeriodLengthDays
• OvertimeAveragingWindowDays
• MonthlyNormMode
• OvertimeAllocationStrategy

Backward compatibility rules

• If new fields are NULL/default → use existing overtime behavior exactly.
• Only activate new period-based logic when OvertimeBasis indicates it AND required parameters are present (or safe defaults are explicitly defined).

---

2️⃣ Overtime Allocation Strategies

Implement allocation strategies:

• LatestFirst
• EarliestFirst
• Proportional

Backward compatibility rules

• Default strategy must match current behavior (confirm by tests).
• Allocation must be deterministic.

---

3️⃣ Day-Type Resolution + Time-Bands (non-breaking)

Resolve day type:

• Weekday
• Saturday
• Sunday
• PublicHoliday
• CompanyHoliday

Apply new rule tables:

• PayDayTypeRules
• PayTimeBandRules

Backward compatibility rules

• If no PayDayTypeRules exist for a ruleset → fall back to current PayDayRules/PayTierRules behavior.
• Do not change existing paycode mapping unless new rules are configured.

---

4️⃣ Holiday Paid-Off Logic (non-breaking)

If employee does not work on public holiday:

• Use PlannedHours
• OR FixedSeconds
• OR None

Generate correct pay lines using configured pay codes.

Backward compatibility rules

• If HolidayPaidOffMode is default/None → preserve current holiday handling.
• If new mode enabled → ensure it does not affect non-holiday days.

---

5️⃣ 11-Hour Rest Rule

Use:

• MinimumDailyRestSeconds
• FirstWorkStartUtc
• LastWorkEndUtc

Add deterministic violation detection logic.
(If existing logic exists, extend it; do not break current outputs.)

---

🌐 API: Controllers + Services (CRUD)

We need API endpoints and service layer for index + CRUD of the new rule entities so Angular frontend can be implemented later.

Entities requiring CRUD

• PayRuleSets (existing)
• PayDayTypeRules (new)
• PayTimeBandRules (new)
• WorkingTimeRuleSets (existing, now extended)
• AssignedSiteRuleSetAssignments (new) — if repository includes employee rule assignment logic

Requirements

• Follow existing architectural patterns (controller → service → repository/data access).
• Include:
  • GET /... list/index (paging optional)
  • GET /.../{id}
  • POST /...
  • PUT /.../{id}
  • DELETE /.../{id} (soft delete if your workflow state model requires it)
• Validate inputs (time band boundaries, overlaps, day type duplicates, etc.).
• Ensure new endpoints do not break existing routes.

---

🧪 Testing Requirements (must-have)

Integration tests (required for ALL controllers/services)

All controllers and services introduced/chan...

• Fixes 🚀 Feature: Extend Rule Engine for Advanced Overtime & Holiday Logic (Non‑Breaking + API CRUD + Tests) #1338

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[renemadsen]

@copilot Stick to our codebase and you can reference https://github.com/microting/eform-timeplanning-base for the entities

[renemadsen]

@copilot We should not include using BackendConfiguration.Pn.Integration.Test; since it's not in our codebase

[Copilot]

Fixed in commit 68fe2a7. Changed TestBaseSetup namespace to TimePlanning.Pn.Test and removed the BackendConfiguration.Pn.Integration.Test using statement from all test files (9 files updated).

[Copilot]

@copilot Stick to our codebase and you can reference https://github.com/microting/eform-timeplanning-base for the entities

Acknowledged. The implementation references entities from Microting.TimePlanningBase v10.0.15 NuGet package. The namespace issue has been fixed in commit 68fe2a7 - all tests now use TimePlanning.Pn.Test namespace consistently with the codebase.