View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005803CaseTalk ModelerValidationpublic2026-07-25 22:222026-07-27 14:44
ReporterMarco Wobben Assigned ToMarco Wobben  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
Target Version15.xFixed in Version15.0 
Summary0005803: Deciding a uniqueness constraint does not ask whether the same fact can recur over time
Description

When a uniqueness constraint is settled for a fact type, the question whether the same participants can be involved again at a later time is left implicit. Two people can marry, divorce and marry again; a treatment can be stopped and started again; an employee can be hired twice by the same employer. In other cases a single occurrence is exactly what is meant.

This cannot be derived from the model: both readings are legitimate and look identical. It is a decision the modeller has to make, and it belongs with the temporal nature of the type, where periods of validity are already recorded.

Expected: while deciding the uniqueness constraint in the wizard, the modeller is asked about this, the answer is kept as the temporal setting of the type, and documentation and generated output reflect it. Where nothing has been declared yet, the model quality report can point that out, so the question is answerable and can be settled rather than repeated.

TagsNo tags attached.
CaseTalk EditionCorporate

Relationships

related to 0005802 resolved Objectified fact types with one participant are classified as kind instead of an aspect 
related to 0005809 resolved Temporal setting cannot record a decision moment without also declaring an effective period 
related to 0005810 resolvedMarco Wobben UC Wizard asks the same questions again for each language of a fact type 

Activities

Marco Wobben

Marco Wobben

2026-07-26 10:07

administrator   ~0008618

This requires some sort of temporal wizard, in which questions are asked about facts over time. A marriage has a historical timeline; an article has one price but can be adjusted over time and pro-actively into the future; a fact can be known before it is registered; ..
Marco Wobben

Marco Wobben

2026-07-26 11:20

administrator   ~0008626

Last edited: 2026-07-27 11:09

Wizard flow. The UC wizard (FORMS/_FUCWIZ.PAS) is a Yes/No state machine over candidate UCs (sValidateSmallUC -> DisplayUC -> confirm, with mStatement and mQuestion), so the follow-up is a new state after a UC is accepted rather than a new dialog.

Q1, existing: can these facts occur at the same time? -> settles the uniqueness constraint.
Q2, new: can the same fact occur again at a different time?
No -> Temporal stays tmNone, and the single occurrence becomes an explicit modelling decision instead of an accident.
Yes -> Q3.
Q3, new: which times does the business need to know about? Asked in business terms, not in temporal-database jargon:
when it holds or became true in the real world, including planned future -> valid time
when it was registered or recorded -> transaction time
when it was decided -> decision time

Issue History

Date Modified Username Field Change
2026-07-25 22:22 Marco Wobben New Issue
2026-07-25 22:22 Marco Wobben Relationship added related to 0005802
2026-07-26 10:07 Marco Wobben Note Added: 0008618
2026-07-26 10:11 Marco Wobben Summary Warn when an objectified relationship cannot occur twice between the same participants => Objectifying a fact type does not ask whether the relationship can recur over time
2026-07-26 10:11 Marco Wobben Description Updated
2026-07-26 11:20 Marco Wobben Note Added: 0008626
2026-07-27 09:20 Marco Wobben Relationship added related to 0005809
2026-07-27 10:26 Marco Wobben Summary Objectifying a fact type does not ask whether the relationship can recur over time => Deciding a uniqueness constraint does not ask whether the same fact can recur over time
2026-07-27 10:26 Marco Wobben Description Updated
2026-07-27 11:09 Marco Wobben Note Edited: 0008626
2026-07-27 11:09 Marco Wobben Note View State: 0008626: public
2026-07-27 13:22 Marco Wobben Relationship added related to 0005810
2026-07-27 14:44 Marco Wobben Assigned To => Marco Wobben
2026-07-27 14:44 Marco Wobben Status new => resolved
2026-07-27 14:44 Marco Wobben Resolution open => fixed
2026-07-27 14:44 Marco Wobben Fixed in Version => 15.0