Tickets.CaseTalk - Issues

0005910: Model check reports an invalid default value on roles that have none

Tue, 18 Aug 2026 13:11:53 +0200

Running the model checks reports "Default Values must comply with datatype" for roles that do not have a default value at all. The reported value looks empty in the message, so the check appears to complain about nothing, and the role it points at is correct as it stands.

The warning only turns up after the model has been edited in the running session; reopening the project makes it go away again.

0005909: Adding an expression to a fact type can make the diagram stop showing its expressions

Tue, 18 Aug 2026 12:53:40 +0200

After adding an extra expression (a fact type expression or an object type expression) to a fact type, the box for that fact type on the diagram can stop showing its expression lines - not only the new expression, but also the ones that were already there.

It happens when the added expression also makes the fact type usable as an object type. The diagram then redraws the box in its object type shape. Boxes whose expression display was switched on by hand, on a diagram where fact type expressions or object type expressions are switched off as a whole, are the ones affected: after the redraw the box follows the diagram-wide setting again, and its expression lines disappear.

Refreshing the object-fact type does not bring them back, so it looks as though the diagram never picked up the new expression at all.

The same redraw loses the box's own settings for showing rules, for showing example data, and for the position of the name.

0005806: Population is not checked against ring constraints

Mon, 17 Aug 2026 14:47:12 +0200

The model quality report checks the population against uniqueness constraints, totality constraints, subset constraints and data types, but not against ring constraints.

As a result a ring constraint can be declared on a fact type while the population contradicts it, and nothing reports it. Examples: a symmetric relationship where both directions have been entered, so the same situation is stated twice; an irreflexive relationship where something is related to itself; an asymmetric relationship where both directions are present; a relationship declared free of cycles where the population contains one.

For a symmetric relationship the useful finding is the redundant one: once symmetry is declared, entering the reverse as well states the same fact twice, which is exactly what a population is supposed to avoid. Both readings can still be verbalized from the single stated fact.

Expected: the population is checked against the declared ring constraint, in the same way as the other constraint types.

0004452: CaseTalk crash at end of classification

Mon, 17 Aug 2026 14:46:57 +0200

At end of classification, CaseTalk stops responding. The screen becomes like an image, without any reaction whatsoever to my mouse.

CTRL+ALT+DEL + end task is the only solution, again losing (classified) expressions.

0005905: Uploading a model could create a new version with missing content, without reporting an error

Mon, 17 Aug 2026 14:46:36 +0200

When a model was uploaded to a SQL Server repository, a row the database rejected could be discarded without any error being shown. The upload continued with the remaining tables, a new version number was created and handed back to the modeller, and the transaction was committed. The result was a version that looked successful but was missing part of the model - in the case that brought this to light, every object-fact type, while all twenty other parts of the model were stored correctly. Opening that version in the portal or downloading it again showed an empty model.

The rejection itself came from model properties added during the 15.0 cycle (definite article, meta level, composite flag, data sensitivity and retention policy). These are mandatory in the repository and carry a default value, but the upload sent an explicit empty value for them instead of letting the default apply, which the database refused. Older models, written before those properties existed, were the ones affected.

0005906: Option to keep diagram images out of project archives

Mon, 17 Aug 2026 14:46:24 +0200

Every time a project is archived - automatically after a save, manually via Archive Project, or through the MCP archives tool - CaseTalk also puts the rendered pictures that sit next to each diagram into the .zip: the PNG, JPG, SVG, WMF and generated HTML exports of every diagram, including the ER, UML, knowledge graph, ArchiMate, mapping, expression and data vault renderings.

Those pictures are rewritten from the diagram on every save and contain nothing the diagram itself does not already hold, yet in a diagram-rich project they are by far the largest thing in the archive. Archives grow into the tens of megabytes and the archive folder fills up fast.

The Files page of the Environment Options now has an 'Archive Diagram Images' checkbox, next to Auto Archive and Optimize Archives. Switch it off and archives contain only the model and diagram files themselves, which keeps them small; the images are still generated on disk as before and are still listed in the project window. The option is on by default, so archives keep working exactly as they always did until it is changed.

This does not affect what CaseTalk renders - the 'Diagram Extras' setting still decides that. It only decides whether those renderings travel along into an archive.

0005908: Population editor puts values in the wrong row or column

Mon, 17 Aug 2026 14:46:10 +0200

Two problems with the values in the population editor.

1. Looking up a row
Looking a value up in the object type a column refers to sometimes puts the values in the wrong columns, and sometimes leaves the last column of that reference untouched, so it keeps the value it had before. It happens when the same label type heads more than one column: a fact type that relates an object type to itself, or a reference identified by, for instance, a start and an end date. The lookup window also opens on the first row rather than on the row the cell already refers to.

2. The Details page
The fields on the Details page keep showing the row that was left. Add a row, or step to the next one, and as soon as a field is left the values of the previous row are written into the current row, which then reads as a copy of its predecessor. In a population that has no rows yet, typing on the Details page overwrites the column headings instead of filling a row.

0005902: A model should be able to say which fact type indicates the subtype

Sun, 16 Aug 2026 17:37:47 +0200

When subtypes are grouped into one table, a record no longer says which subtype it is. The answer is a fact type that carries the subtype name - a subtype discriminator - but nothing in a model can state that a fact type plays that part. Every feature that needs to know therefore guesses, and each one guesses differently.

The model quality report infers it: it accepts any population value in the model that happens to equal a subtype's name. The transformation cannot ask at all, so it groups subtypes whether or not the answer is recoverable afterwards. The generator cannot emit the column, because it does not know which fact type to emit. And the wizards cannot offer to create one, because there is nothing to create.

Expected: a fact type can be marked as the subtype discriminator for a supertype, stored as part of the model rather than inferred from the data in it. Once a model can say it:

- the quality report checks that discriminator's population against the actual list of subtypes, instead of matching names anywhere in the model
- the transformation knows whether grouping keeps the subtypes recoverable, and can offer to add the discriminator when it does not
- the generator emits the column with a value constraint limited to the subtypes in that table
- the wizards can propose one while the subtypes are being defined

Detection can lean on what a model already offers: a fact type given the Classification concept type is stating that it classifies, which is a strong candidate for the discriminator and can be proposed as such.

This is the shared foundation for the requests that have each been waiting on it.

0000679: Prompt for subtype indication

Sun, 16 Aug 2026 16:54:24 +0200

The UC/TC Assistent could be extended to ask if an OTFT containing a single role is actually a subtype, once it is matched to an OT, or once it generates two layers of OT.

0000120: Create a binairy fact with subtype indications

Sun, 16 Aug 2026 16:54:21 +0200

Performing a GLR on a structure containing subtypes, a table may be created containing several of these conceptual subtypes. However, which subtype a record represents is no longer clear.

Analists are adviced to add a binary fact type expression which may hold the subtypes indication in the DBMS. It is than up to the DBA to decide to keep it or not.

It would be great to have CaseTalk generate this column with a value constraint limited to either of the subtypes contained in the table. This takes a load of the shoulders of the analist. And makes it more intuïtive to work with the conceptual info, without the need to remember these special operations.

0000230: Cannot open multiple IG files

Sun, 16 Aug 2026 15:29:16 +0200

It would be nice to open multiple IG files within the same project. Either both IG and IGG, or differenet IG files to be able to compare them.

0005816: Filtering OTFT appears to show no results

Sun, 16 Aug 2026 13:13:58 +0200

The filtering of otfts sometimes seems to not update the histlist, and it appears as if there is no hit at all. But when the panel is resized, the hits suddenly show up.

0005894: Ranges, key-labels and state machines in a value constraint are read as plain values

Sun, 16 Aug 2026 13:10:44 +0200

A value constraint can hold more than a plain list of values: a range (for example [1..) or (0..100]), a key with a label (F=Female), or a state machine. In several places the constraint is read as though every entry were a plain value, so fragments such as "[1", "F=Female" or a state name are treated as if they were example values of the label type.

This has two separate consequences.

1. The label type's data type is degraded.

When the data type is derived from the model - which happens automatically when an expression is entered, and on demand through the Derive Data Types action - those fragments are not valid numbers or dates, so the data type is widened to text. A label type that was correctly typed as date, integer or numeric silently becomes text, and that wrong type carries on into the internal schema, generated DDL, the MIM report and other documentation.

2. Generated artifacts receive the wrong values.

When a domain is generated, each entry of the constraint is emitted as a value of that domain. So the generated artifact lists "[1..)" or "F=Female" as if they were allowed values, instead of a proper range or the key alone. The same constraint is also emitted translated in one place and untranslated in another.

Plain enumerated values are not affected by either. Only ranges, key-label pairs and state machines trigger it.

Ranges became sensitive to this when the bracket notation ([1..) and (0..100]) was introduced - before that, a range still split into clean bounds.

0005901: Improved value constraint type support in artifacts: ranges, state machines and key-label

Sun, 16 Aug 2026 11:12:53 +0200

A value constraint says one of four things: a list of values, a range, a key with a label, or a state machine. Artifacts only ever handled the first properly. Everything else was flattened into a list of allowed values, which loses most of what was written:

- a range ended up inside that list, so a generated check read as though "1..10" were itself a value;
- a key lost its label - "F=Female" arrived as "F", and Female was nowhere in the generated result;
- a state machine arrived as a flat list of state names, and which state may follow which was gone;
- the marker for where a machine starts came out as though it were a state.

Artifacts should carry each kind as what it is.

A list of values and a key with a label become a reference table: a row per value, a column for the label where there is one, filled as static population, with a foreign key from every column that uses the domain. The check constraint is then simpler or unnecessary, because the database enforces the values by reference, and the labels can be joined against instead of being discarded.

A state machine becomes two tables: the states, and the transitions as pairs of from-state and to-state. Which state may follow which cannot be expressed as a check constraint at all.

Where a machine says it starts becomes the default value of the column, when the role does not already state one of its own. The start marker itself is never a value and never appears as one.

A range stays a check constraint. A range is continuous, so it cannot be listed as rows - "between 1 and 10" is not the statement "1 or 10" - and the brackets decide whether a bound is included.

Generating the reference tables should be a setting, since not every target wants extra tables in its schema.

0005899: Editing a population fails with "Out of system resources" after a lookup

Sun, 16 Aug 2026 06:44:45 +0200

Opening the population editor for a fact type, using Lookup to pick a value and then clicking around the grid can end with the message "Out of system resources". Before that the dialog becomes very slow, and the empty row at the bottom of the grid shows an absurdly high row number (for example 51501) even though the population only holds a couple of rows.

The population editor treated the highest row number in use as if every number below it were a row, and quietly created an empty placeholder row for each number that was missing. Those placeholders then counted towards the highest number in use, so the gap could only ever grow: each time the editor was opened it had more placeholders to create than the time before. Because a Lookup opens a second population editor, looking a value up made it grow faster. Once the numbering had run up into the tens of thousands, simply opening the editor allocated tens of thousands of placeholder rows and the program ran out of memory.

Fixed: the editor now asks for a row's values first and only keeps a row that actually has any, so gaps in the numbering cost nothing. Saving a population no longer re-scans the whole population once per row, which also removes the long delay when closing the dialog. A third problem was corrected along the way: when the numbering was tidied up on save, an empty gap could be renumbered onto a number already in use, putting two rows on the same number.

A model that has already been affected keeps its inflated numbering. Run the model checks: the population check reports the bad rows and numbering gaps, and its Fix removes the leftover placeholder rows and renumbers the population back down.

0005895: Label types that take their data type from another label type are treated as untyped

Sat, 15 Aug 2026 21:08:21 +0200

A label type does not have to name one of the built-in data types directly. It may point at another label type acting as a domain - for example "Birth Date" whose data type is "Date", where "Date" is itself a label type carrying the data type date.

Several parts of the product only read the name written on the label type itself. Because that name ("Date") is not one of the built-in type names, they conclude the label type has no data type at all, and fall back to a default.

Visible effects:
- a label type using a domain is reported as having no data type;
- whether its values are quoted in generated output is decided by a fallback rather than by the real type;
- exports and reports that branch on the data type take the wrong branch;
- data type derivation skips the label type.

What is needed is one place that answers "what is the actual data type of this label type", following the chain to the domain that defines it, so that every part of the product gives the same answer. The chain is already walked when the data type is shown as text, including protection against a definition that points at itself, so the behaviour exists - it is simply not available to the places that need to act on it.

This blocks the value storage and rendering work in 0003773, and part of the fix for 0005894.

0005898: A label subtype must not allow more than its supertype

Sat, 15 Aug 2026 20:05:50 +0200

A label subtype takes its data type from another label type acting as a data domain. Its value constraint therefore has to stay inside the one its supertype states: a subtype is allowed to be stricter, never wider.

Until now nothing checked this. A subtype could state a range of 0..100 under a supertype stating 10..50, or list a value the supertype does not allow at all, and the model would report no problem - even though the two rules contradict each other and no value can satisfy both.

A model check now reports it: "A label subtype may not allow more than its supertype." Each value or range that steps outside the supertype is listed separately, naming the subtype and the supertype involved, and the fix opens the constraint of the subtype - the one making the wider claim.

What counts as allowed:
- a listed value has to be one the supertype allows;
- a key with a label is judged on the key, so a subtype may give the same key a different label;
- a state machine is judged on the state names it mentions;
- a range has to lie inside a range the supertype states. Where the bounds are equal, the brackets decide: a supertype that excludes a bound is not satisfied by a subtype that includes it. An end left open is outside any end the supertype closes.

A range is deliberately not judged against a list of single values, because a list of 1 and 10 does not admit everything between them.

A supertype that states no constraint at all restricts nothing, so nothing can contradict it. Where a domain in between states nothing, the check looks further up to the first constraint there actually is.

Split from 0005890, which also raises size and precision inheritance and a wiki clarification of what a label type means - those are still open there.

0005897: Ring constraints are drawn wrong when the diagram is not at 100% zoom

Sat, 15 Aug 2026 18:08:11 +0200

Ring constraint markers do not follow the diagram cleanly when the zoom is not 100%.

- A marker that was dragged to its own spot stays where it was, so it drifts away from its fact type a little further with every zoom step.
- The marker is drawn with a thin hairline while the rest of the diagram thickens its lines with the zoom, so it looks faint when zoomed in and washes out on a print or exported image.
- Zoomed far out the symbols inside the rings stop shrinking with the diagram and turn into blobs: the arrowheads and dots reach a minimum size and fill the circle.

Steps to reproduce:
1. Open a diagram with a fact type carrying a ring constraint.
2. Drag the ring marker beside the fact type.
3. Zoom in and out a few times, then print or export the diagram.

Expected: the marker keeps its place relative to the fact type, and its lines and symbols scale with the rest of the diagram at every zoom level.

0005892: Show which role wins the grouping tiebreak in the diagram

Sat, 15 Aug 2026 15:48:33 +0200

On a binary fact type between two object types, both roles are marked as groupable, because both of them genuinely satisfy the grouping rules. When exactly one of the two carries a single-role totality constraint, though, the transformation will always take that one - the direction is settled - and the diagram gives no hint of it.

Show which role wins by printing its mark in bold. Both roles stay marked, so the mark keeps its present meaning of "this role qualifies"; the weight adds "and this is the one that will be taken".

This also makes the diagram agree with the model check: a bold mark appears exactly when the check stays silent about grouping preference. If neither role carries a totality constraint, or both do, nothing is bold and the check asks for a preference - which is the honest picture, because the choice really is open.

0003408: Render datetime formats according to Locale

Sat, 15 Aug 2026 15:47:16 +0200

The date time type for string values should be rendered back to the user using the selected Locale Setting.

0005893: Model checks and the API read a transformation setting as if it were part of the model

Sat, 15 Aug 2026 14:34:09 +0200

The "force not null" setting on a role is an instruction to the transformation. It lets a modeller force a NOT NULL column in the generated result without stating the underlying rule in the model itself - which is why it can only be set before a transformation has run.

Two model checks and the API read it as though it were part of the model instead. The API in particular reports a role as "not optional" purely because this setting is on, which tells a caller something about the intended output while appearing to describe the model.

The setting should be honoured where the transformation is decided, and ignored where the model itself is being described or checked.

0005748: Binary fact grouping rule: false grouping-preference warning when totality constraint already determines direction

Sat, 15 Aug 2026 13:03:58 +0200

On a binary fact type between two objectified fact types with two single-role uniqueness constraints, the model-quality rule that asks the user to choose a grouping direction fired even when the direction was already unambiguous. When exactly one of the two roles carries a single-role totality constraint, the group/lexicalize engine already groups that role preferentially, so no user preference is needed. The rule nonetheless reported a violation, producing a false positive that was inconsistent with the engine's actual behaviour.

0005889: Files kept outside the project folder are re-searched on every open, and may be matched to the wrong file

Fri, 14 Aug 2026 18:56:43 +0200

A project can refer to files that are not stored in the project folder itself. CaseTalk remembers where those files live through a Windows shortcut, so that the project keeps working when a file is moved elsewhere on the same computer.

Two things go wrong with that.

Opening a project is slow when such a file has moved. Windows is able to find the file in its new place, but CaseTalk does not remember the answer: the shortcut on disk keeps pointing at the old location, so the search starts again from scratch the next time the project is opened, and the time before that. Windows allows itself three seconds for each search. A project holding a dozen or more external files can therefore appear to hang for the better part of a minute on every open, showing nothing at all while it waits.

A file can also be silently replaced by the wrong one. When Windows can no longer follow a file, it falls back to looking for one with the same name, and that search can land on an unrelated file elsewhere on the machine. The project then quietly starts working with a file the user never chose.

Note that this way of remembering files only works within one computer. A project folder that travels through a sync service such as OneDrive arrives on the other machine as a fresh copy, and no shortcut in it can be followed. For that reason files belonging to a project are best kept in the project folder itself.

0005884: Hide example data from readers who are not cleared for it

Thu, 13 Aug 2026 09:33:24 +0200

A model's example population is often real: rows lifted from a production system to make a fact type concrete. Until now CaseTalk showed all of it to whoever had the file open, and printed all of it into reports.

Expected: what a reader sees depends on what they are cleared to see.

- A permission level in the options says what the person at this CaseTalk may read. Everything remains readable by default, exactly as before.
- Example data classified above that level is shown as a placeholder instead of the real value, wherever a sentence is verbalized.
- A single tuple can state its own classification, which overrides the object/fact type in both directions. This matters because example data is not all of a kind: a row somebody invented to illustrate a fact type is marked Public and stays readable however sensitive the type is, while a row taken from production stays protected however ordinary the type looks.
- The population editor shows masked rows as such and will not let them be edited, since what is on screen is a placeholder and typing over it would replace the real value. A deliberate 'Reveal masked values' step lifts that for the current editing session, in the same way an object/fact type is temporarily unlocked, and it is handed back when the editor closes.
- The project report carries a confidentiality notice when the model classifies anything, because once a report leaves CaseTalk there is no reader left to check.

0004024: For your eyes only - classifications

Thu, 13 Aug 2026 09:33:24 +0200

According to a post on LinkedIn this makes sense for modeling (artifacts).

[url=https://www.linkedin.com/feed/update/urn:li:activity:7084824295603884032" rel="noopener,nofollow]https://www.linkedin.com/feed/update/urn:li:activity:7084824295603884032[/url]