Implement PayRuleSet CRUD with time-threshold tiers matching backend schema

[Copilot]

Angular implementation used percentage-based tier allocation (tierPercent: 70%) while backend schema expects time-threshold tiers (upToSeconds: 28800). Additionally, nested tier data wasn't persisting.

Schema Alignment

Day identification:

• Changed dayOfWeek: number (0-6) → dayCode: string (SUNDAY, MONDAY, WEEKDAY, HOLIDAY, GRUNDLOVSDAG)

Tier structure:

• Removed tierNumber, tierPercent, payCodeId
• Added order: int, upToSeconds: int?, payCode: string
• Removed percentage sum validation (tiers must sum to 100%)
• Time thresholds now define pay code transitions

// Before (incorrect)
{ dayOfWeek: 1, payTierRules: [
  { tierNumber: 1, tierPercent: 70, payCodeId: 1 }
]}

// After (matches backend)
{ dayCode: "MONDAY", payTierRules: [
  { order: 1, upToSeconds: 28800, payCode: "REG" },
  { order: 2, upToSeconds: null, payCode: "OT" }
]}

Updated components: PayDayRuleForm, PayDayRuleList, PayDayRuleDialog, Create/Edit modals.

UI Fixes

Add Tier button not working:

• mat-table doesn't auto-detect FormArray changes
• Implemented MatTableDataSource with explicit updateTable() calls
• Added FormControl type casting to prevent binding errors

Form validation:

• Trigger markAsDirty() and updateValueAndValidity() after FormArray modifications
• Save button now properly reflects form state

Data Persistence

Added missing payTierRules: PayTierRuleModel[] to PayDayRuleModel. Tier data was being dropped during serialization.

Diagnostics

Added console logging to create/edit flows for troubleshooting save issues (form validity, data structure, API responses).

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.