mAi
7d7b20651d
Engine side of the four Verfahrensablauf appeal bugs in m/paliad#136. Bug 2 — Missing trigger event row. When CalcOptions.AppealTarget is set, Calculate now prepends a synthetic TimelineEntry to the deadlines slice dated to the trigger date, carrying the per-appeal-target label from TriggerEventLabelForAppealTarget (Endentscheidung (R.118), Kosten- entscheidung, Anordnung, Schadensbemessung, Bucheinsicht). Marked IsRootEvent + IsTriggerEvent + party=court + priority=informational so the frontend renders it as a dimmed anchor card without a save button / choices caret / click-to-edit affordance. Empty Code so it doesn't collide with real rule UUIDs downstream. Bug 1 (engine half) — Side selector dead on appeal. Every appeal filing rule carries primary_party='both' in the catalog, so the column bucketer couldn't distinguish Berufungskläger vs Berufungs- beklagter filings from primary_party alone. Engine now stamps the new TimelineEntry.AppealRole field with appellant/appellee from the rule-semantic AppealFilerRole mapping (appeal_role.go) when an appeal_target is in scope. The frontend half of the fix (next commit) consumes this to route each "both" rule into the user-perspective column once the user picks a side. Mapping covers all 12 appeal filing rules across the three applies_to_target tracks (endentscheidung/schadensbemessung, kostenentscheidung, anordnung/bucheinsicht). Court-issued events (merits.decision, merits.oral, cost.decision, order.order) stay empty — they continue to route on Party='court'. Unmapped submission_codes return empty so a new appeal rule we forgot to map falls through to the bucketer's legacy path rather than silently picking a side. Tests: TestAppealFilerRole pins the mapping; TestCalculate_Appeal SyntheticTriggerRow covers (a) synthetic row prepended + AppealRole stamped when target is set, (b) no synthetic row + no AppealRole when target is unset (regression guard), (c) unknown target short-circuits to no-op. Existing tests untouched — both behaviours gate on opts.AppealTarget != "". No DB migration — the bugs are calc-side. deadline_rules untouched.
59 lines
2.4 KiB
Go
59 lines
2.4 KiB
Go
package litigationplanner
|
|
|
|
// AppealRole* are the canonical filer-role slugs used by the unified
|
|
// upc.apl Berufung proceeding (t-paliad-307 / m/paliad#136 Bug 1).
|
|
//
|
|
// Every appeal filing rule carries primary_party='both' in the catalog
|
|
// (either party could be the appellant, depending on which side lost
|
|
// downstream), so the static primary_party column can't drive
|
|
// column-bucketing under a user-perspective `?side=` pick. The
|
|
// per-rule appeal role fills that gap: "appellant" rules are filed by
|
|
// the Berufungskläger (the party who lost in the lower instance and
|
|
// is now appealing); "appellee" rules are filed by the
|
|
// Berufungsbeklagter (the party defending the lower-instance
|
|
// decision). The mapping is rule-semantic, not data-driven — we know
|
|
// from R.224/235 which submission belongs to which side.
|
|
const (
|
|
AppealRoleAppellant = "appellant"
|
|
AppealRoleAppellee = "appellee"
|
|
)
|
|
|
|
// AppealFilerRole returns the appeal-filer role for a submission code
|
|
// in the unified upc.apl proceeding. Empty string for codes whose role
|
|
// is not statically known (court-issued events, unmapped codes, or
|
|
// non-appeal proceedings).
|
|
//
|
|
// The engine stamps TimelineEntry.AppealRole with this value when
|
|
// CalcOptions.AppealTarget is set so the frontend column-bucketer can
|
|
// route each "both"-party rule into the correct user-perspective
|
|
// column (Berufungskläger vs Berufungsbeklagter) once the user picks
|
|
// a side.
|
|
//
|
|
// Adding a new appeal rule? Add its submission_code to the matching
|
|
// branch below. Court-issued events (cost.decision, order.order,
|
|
// merits.oral, merits.decision) deliberately stay empty — they route
|
|
// to the court column on primary_party='court'.
|
|
func AppealFilerRole(submissionCode string) string {
|
|
switch submissionCode {
|
|
// Appellant filings — Berufungskläger initiates the appeal +
|
|
// replies to the cross-appeal.
|
|
case "upc.apl.merits.notice",
|
|
"upc.apl.merits.grounds",
|
|
"upc.apl.merits.cross_a_reply",
|
|
"upc.apl.cost.leave_app",
|
|
"upc.apl.order.with_leave",
|
|
"upc.apl.order.grounds_orders",
|
|
"upc.apl.order.discretion",
|
|
"upc.apl.order.cross_reply":
|
|
return AppealRoleAppellant
|
|
// Appellee filings — Berufungsbeklagter responds to the appeal +
|
|
// files the cross-appeal.
|
|
case "upc.apl.merits.response",
|
|
"upc.apl.merits.cross_a",
|
|
"upc.apl.order.response_orders",
|
|
"upc.apl.order.cross":
|
|
return AppealRoleAppellee
|
|
}
|
|
return ""
|
|
}
|