View Issue Details

IDProjectCategoryView StatusLast Update
0005853CaseTalk ModelerExpressionspublic2026-08-05 19:49
ReporterMarco Wobben Assigned To 
PriorityhighSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Target Version15.0 
Summary0005853: Alter Played By picks the wrong specialization when a role is moved between generalizations
Description

Using "Alter Played By..." on a role works as expected for ordinary object and fact types, but fails when the role is moved from one generalized object type to another.

A generalization does not have a single expression standing for the whole type - it has one expression per specialization underneath it. When the role's new player is a generalization, CaseTalk does not ask which specialization is meant. It silently takes the first one it happens to find, so the role ends up attached to an arbitrary single specialization instead of to the generalization as a whole.

This only becomes obvious when the role was ALSO played by a generalization before the change. In that case the role already had one substitution for each branch of the old generalization. All of those branches are pointed at the same single expression of the new generalization, and the surplus ones are then discarded without warning. What was a role played by a generalization with several specializations comes back as a role tied to just one of them, so the resulting expressions in the before/after preview are wrong or incomplete and the change has to be cancelled.

In addition, when the two generalizations are unrelated (they usually are), the uniqueness and subset constraints that were on the role are removed as part of the change.

Workaround: adjust the substitution for the role by hand through expression input after the change, or rebuild the role rather than altering its played-by.

TagsNo tags attached.
CaseTalk EditionCorporate

Activities

Marco Wobben

Marco Wobben

2026-08-05 19:45

administrator   ~0008786

Fixed for 15.0.

Moving a role's played-by from one generalized object type to another now keeps every branch. Each of the role's readings is re-pointed at the matching specialization of the new generalization, in the same order, instead of all of them being pushed onto whichever specialization happened to come first. Where the new generalization has fewer specializations than the old one, the remaining readings fall back to its last one, and a reading that would duplicate another is dropped rather than causing an error.

Note that the uniqueness and subset constraints that were on the role are still removed when the old and new player are not part of the same subtype branch, which is normally the case for two separate generalizations. That behaviour is unchanged.

Issue History

Date Modified Username Field Change
2026-08-05 19:02 Marco Wobben New Issue
2026-08-05 19:43 Marco Wobben Target Version => 15.0
2026-08-05 19:44 Marco Wobben Status new => resolved
2026-08-05 19:44 Marco Wobben Resolution open => fixed
2026-08-05 19:45 Marco Wobben Note Added: 0008786