Skip to content

Docs for data model fields calculation by expression#2763

Open
olavsorl wants to merge 5 commits intomasterfrom
feature/docs-expression-calculation
Open

Docs for data model fields calculation by expression#2763
olavsorl wants to merge 5 commits intomasterfrom
feature/docs-expression-calculation

Conversation

@olavsorl
Copy link

@olavsorl olavsorl commented Mar 9, 2026

Summary by CodeRabbit

  • Documentation
    • Added new documentation on configuring data field calculations using dynamic expressions.
    • Fixed a typographical error in expressions documentation.
    • Corrected JSON syntax in validation examples.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Mar 9, 2026

Note

.coderabbit.yaml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)
Validation error: Unrecognized key(s) in object: 'auto_resolve_threads'
⚙️ Configuration instructions
  • Please see the configuration documentation for more information.
  • You can also validate your configuration using the online YAML validator.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
📝 Walkthrough

Walkthrough

New documentation files for data field calculations using expressions are introduced in English and Norwegian Bokmål. Additionally, minor corrections are made including a typo fix and JSON syntax corrections in existing documentation.

Changes

Cohort / File(s) Summary
Calculation Documentation
content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.en.md, content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.nb.md
New documentation describing how to configure data field calculations using the expression engine via calculation.json schema, file naming conventions, templates, and concrete examples.
Documentation Corrections
content/altinn-studio/v8/reference/logic/expressions/_index.nb.md, content/altinn-studio/v8/reference/logic/validation/expression-validation/_index.nb.md
Typo fix (spesifikk) and removal of trailing commas in JSON example syntax to correct validation and expression documentation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

📚 New calculations documented with care,
English and Bokmål both laid bare,
A typo squashed, commas made clean,
The clearest docs you've ever seen! ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: adding documentation for data model field calculations using expressions, which is the primary focus of this PR.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feature/docs-expression-calculation

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 6

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
content/altinn-studio/v8/reference/logic/validation/expression-validation/_index.nb.md (1)

101-112: ⚠️ Potential issue | 🟠 Major

example2.validation.json is still invalid JSON.

There is still a trailing comma on Line 112, so this example cannot be copied as valid JSON even after the comma removal above.

Suggested fix
       "condition": [
         "or",
         ["contains", ["lowercase", ["dataModel", ["argv", 0]]], "æ"],
         ["contains", ["lowercase", ["dataModel", ["argv", 0]]], "ø"],
-        ["contains", ["lowercase", ["dataModel", ["argv", 0]]], "å"],
+        ["contains", ["lowercase", ["dataModel", ["argv", 0]]], "å"]
       ]
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@content/altinn-studio/v8/reference/logic/validation/expression-validation/_index.nb.md`
around lines 101 - 112, The JSON in the "tegn-ikke-tillatt" definition is
invalid due to a trailing comma after the last condition array element; remove
the trailing comma after the ["contains", ["lowercase", ["dataModel", ["argv",
0]]], "å"] entry so the "condition" array and the "tegn-ikke-tillatt" object
become valid JSON (locate the "tegn-ikke-tillatt" definition and edit its
"condition" array to eliminate the final comma).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.en.md`:
- Around line 54-58: The phrase "any object type" in the description of a
calculation rule's condition is too vague—update the text that describes the
return value of the condition in the `calculations` documentation to enumerate
the supported return types from the dynamic expressions system (e.g., boolean,
number, string, null, object, and array) and briefly note any constraints (for
example: objects/arrays must be serializable and expressions cannot return
functions), referencing the `calculations` object and the `condition` concept
and keeping the link to the dynamic expressions docs for details.
- Around line 44-47: The example uses inconsistent function casing — "datamodel"
vs "dataModel" — which will break; update the example so both lookups use the
actual function name "dataModel" (replace "datamodel" with "dataModel") in the
"condition" expression so the calls to dataModel("regnskap.inntekter") and
dataModel("regnskap.utgifter") are consistent.

In
`@content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.nb.md`:
- Around line 54-58: The description for calculation rules is too vague: replace
"returnerer en hvilke som helst objekttype" with a narrow list of supported
expression return types and state the expected type for a rule condition — e.g.,
clarify in the `calculations` documentation that a rule's `condition` (see
`dynamiske uttrykk`) must evaluate to a boolean (or other supported scalar types
such as number or string where relevant), and that complex object/list values
are not valid return types for these expressions.
- Around line 7-18: Polish the Bokmål in the intro: fix typos and improve
phrasing (e.g., change "uttryk" to "uttrykk", "navne-konvensjonen" to
"navnekonvensjonen", and replace "json schema spec" with a proper term like
"JSON Schema-spesifikasjon"), and rework sentences for smooth Norwegian (for
example rephrase the first line to something like "Kalkulering av datafelt ved
hjelp av uttrykk gjør det mulig å sette felt i datamodellen ved hjelp av en JSON
Schema-spesifikasjon."), and ensure the examples `navn.calculation.json` and
`skjema.calculation.json` remain clear and consistent with the surrounding text.
- Around line 44-47: The example's expression uses the incorrect function name
"datamodel" inside the "condition" array (the element ["datamodel",
"regnskap.inntekter"]) which should match the documented "dataModel" function;
update that element to use "dataModel" so both operands use the same correct
function name (e.g., replace ["datamodel", "regnskap.inntekter"] with
["dataModel", "regnskap.inntekter"] in the "condition" array alongside the
existing ["dataModel", "regnskap.utgifter"]).

In `@content/altinn-studio/v8/reference/logic/expressions/_index.nb.md`:
- Around line 1081-1082: The sentence "Funksjoner i uttrykkene har en
forventning om at argumentene som blir sendt inn har en spesifikk type." is
ungrammatical—update it to include the missing conjunction or comma for clarity
(e.g., "Funksjoner i uttrykkene har en forventning om at argumentene som blir
sendt inn, har en spesifikk type." or "Funksjoner i uttrykkene har en
forventning om at argumentene som blir sendt inn og har en spesifikk type.") so
the clause reads correctly; locate the exact sentence in the expressions
documentation (the paragraph starting with "Funksjoner i uttrykkene...") and
replace it with the corrected phrasing following Norwegian Bokmål grammar rules.

---

Outside diff comments:
In
`@content/altinn-studio/v8/reference/logic/validation/expression-validation/_index.nb.md`:
- Around line 101-112: The JSON in the "tegn-ikke-tillatt" definition is invalid
due to a trailing comma after the last condition array element; remove the
trailing comma after the ["contains", ["lowercase", ["dataModel", ["argv", 0]]],
"å"] entry so the "condition" array and the "tegn-ikke-tillatt" object become
valid JSON (locate the "tegn-ikke-tillatt" definition and edit its "condition"
array to eliminate the final comma).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 4e21f142-a8b2-4a6d-92a7-9bf4427f6967

📥 Commits

Reviewing files that changed from the base of the PR and between 07e651b and 924ed30.

📒 Files selected for processing (4)
  • content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.en.md
  • content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.nb.md
  • content/altinn-studio/v8/reference/logic/expressions/_index.nb.md
  • content/altinn-studio/v8/reference/logic/validation/expression-validation/_index.nb.md

Comment on lines +44 to +47
"condition":
["minus",
["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

The example should use dataModel consistently.

The first lookup uses datamodel, while the second uses dataModel. If dataModel is the actual function name, this example will fail when copied as written.

Suggested fix
         "condition":
           ["minus",
-            ["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
+            ["dataModel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
           ]
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
"condition":
["minus",
["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
]
"condition":
["minus",
["dataModel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
]
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.en.md`
around lines 44 - 47, The example uses inconsistent function casing —
"datamodel" vs "dataModel" — which will break; update the example so both
lookups use the actual function name "dataModel" (replace "datamodel" with
"dataModel") in the "condition" expression so the calls to
dataModel("regnskap.inntekter") and dataModel("regnskap.utgifter") are
consistent.

Comment on lines +54 to +58
The rules for the fields in the data model are set in the `calculations` object, where the data model path is the key and the value is a list of rules.

Unlike validation using expressions, calculations using expressions do not support lists.

A rule consists of a **condition**, which is a dynamic expression that returns any object type. See [dynamic expressions](/altinn-studio/v8/reference/logic/expressions/) for more information.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

any object type is too broad here.

This reads as if calculation expressions can return arbitrary object values, but the linked expressions docs describe a constrained set of supported value types. Please document the supported/expected return types here instead of “any object type”.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.en.md`
around lines 54 - 58, The phrase "any object type" in the description of a
calculation rule's condition is too vague—update the text that describes the
return value of the condition in the `calculations` documentation to enumerate
the supported return types from the dynamic expressions system (e.g., boolean,
number, string, null, object, and array) and briefly note any constraints (for
example: objects/arrays must be serializable and expressions cannot return
functions), referencing the `calculations` object and the `condition` concept
and keeping the link to the dynamic expressions docs for details.

Comment on lines +7 to +18
Kalkulering av datafelt ved hjelp av uttrykk gjør det mulig
å sette datamodellfelt med uttryksmotoren gjennom en json
schema spec.

## Hvordan konfigurere kalkulering med uttrykk

{{% notice info %}}
Kalkulering med uttrykk kan ikke konfigureres igjennom Altinn Studio Designer per nå.
{{% /notice %}}

Kalkulering med uttryk defineres i en egen fil ved siden av datamodellen din, og bruker navne-konvensjonen `navn.calculation.json`.
Hvis datamodellen din heter `skjema` skal du blant annet ha filene `skjema.cs` og `skjema.schema.json` fra før, og da skal filen du oppretter ligge i samme mappe, og hete `skjema.calculation.json`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Polish the Bokmål in the intro before publishing.

This section still has a few visible language issues (json schema spec, uttryk, navne-konvensjonen), so the page reads unfinished in nb-NO.

As per coding guidelines, **/*.nb.md: Check for Norwegian Bokmål (nb-NO) grammar and spelling with extra care.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.nb.md`
around lines 7 - 18, Polish the Bokmål in the intro: fix typos and improve
phrasing (e.g., change "uttryk" to "uttrykk", "navne-konvensjonen" to
"navnekonvensjonen", and replace "json schema spec" with a proper term like
"JSON Schema-spesifikasjon"), and rework sentences for smooth Norwegian (for
example rephrase the first line to something like "Kalkulering av datafelt ved
hjelp av uttrykk gjør det mulig å sette felt i datamodellen ved hjelp av en JSON
Schema-spesifikasjon."), and ensure the examples `navn.calculation.json` and
`skjema.calculation.json` remain clear and consistent with the surrounding text.

Comment on lines +44 to +47
"condition":
["minus",
["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

The example uses the wrong expression function name.

Line 46 uses datamodel, but the documented function name elsewhere is dataModel. Readers copying this example will get a non-working expression.

Suggested fix
         "condition": 
           ["minus", 
-            ["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
+            ["dataModel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
           ]
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
"condition":
["minus",
["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
]
"condition":
["minus",
["dataModel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"]
]
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.nb.md`
around lines 44 - 47, The example's expression uses the incorrect function name
"datamodel" inside the "condition" array (the element ["datamodel",
"regnskap.inntekter"]) which should match the documented "dataModel" function;
update that element to use "dataModel" so both operands use the same correct
function name (e.g., replace ["datamodel", "regnskap.inntekter"] with
["dataModel", "regnskap.inntekter"] in the "condition" array alongside the
existing ["dataModel", "regnskap.utgifter"]).

Comment on lines +54 to +58
Reglene for feltene i datamodellen settes i `calculations`-objektet, hvor datamodell-stien er nøkkelen, og verdien er en liste med regler.

I motsetning til validering ved hjelp av uttrykk, støtter ikke kalkuleringer ved hjelp av uttrykk lister.

En regel består av en **condition**, som er et dynamisk uttrykk som returnerer en hvilke som helst objekttype. Se [dynamiske uttrykk](/nb/altinn-studio/v8/reference/logic/expressions/) for mer informasjon. No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Please narrow the return-type description here.

returnerer en hvilke som helst objekttype looks incorrect for the expression engine. The expressions reference documents supported datatypes, and object/list values are not generally supported results to work with here. This should describe a supported value type instead of “any object type”.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.nb.md`
around lines 54 - 58, The description for calculation rules is too vague:
replace "returnerer en hvilke som helst objekttype" with a narrow list of
supported expression return types and state the expected type for a rule
condition — e.g., clarify in the `calculations` documentation that a rule's
`condition` (see `dynamiske uttrykk`) must evaluate to a boolean (or other
supported scalar types such as number or string where relevant), and that
complex object/list values are not valid return types for these expressions.

Comment on lines +1081 to 1082
Funksjoner i uttrykkene har en forventning om at argumentene som blir sendt inn har en spesifikk type. Dersom et argument
blir sendt inn har en annen type enn forventet, blir verdien forsøkt konvertert til riktig type. Som et eksempel
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix the sentence grammar here.

The typo is fixed, but the sentence is still ungrammatical: blir sendt inn har en annen type. Please add og or rewrite it, e.g. argumentene som blir sendt inn, har en spesifikk type.

As per coding guidelines, **/*.nb.md: Check for Norwegian Bokmål (nb-NO) grammar and spelling with extra care.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@content/altinn-studio/v8/reference/logic/expressions/_index.nb.md` around
lines 1081 - 1082, The sentence "Funksjoner i uttrykkene har en forventning om
at argumentene som blir sendt inn har en spesifikk type." is
ungrammatical—update it to include the missing conjunction or comma for clarity
(e.g., "Funksjoner i uttrykkene har en forventning om at argumentene som blir
sendt inn, har en spesifikk type." or "Funksjoner i uttrykkene har en
forventning om at argumentene som blir sendt inn og har en spesifikk type.") so
the clause reads correctly; locate the exact sentence in the expressions
documentation (the paragraph starting with "Funksjoner i uttrykkene...") and
replace it with the corrected phrasing following Norwegian Bokmål grammar rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant