Docs for data model fields calculation by expression#2763
Docs for data model fields calculation by expression#2763
Conversation
|
Note
|
| 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.
Comment @coderabbitai help to get the list of available commands and usage tips.
There was a problem hiding this comment.
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.jsonis 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
📒 Files selected for processing (4)
content/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.en.mdcontent/altinn-studio/v8/reference/logic/dataprocessing/calculation/_index.nb.mdcontent/altinn-studio/v8/reference/logic/expressions/_index.nb.mdcontent/altinn-studio/v8/reference/logic/validation/expression-validation/_index.nb.md
| "condition": | ||
| ["minus", | ||
| ["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"] | ||
| ] |
There was a problem hiding this comment.
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.
| "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.
| 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. |
There was a problem hiding this comment.
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.
| 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`. |
There was a problem hiding this comment.
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.
| "condition": | ||
| ["minus", | ||
| ["datamodel", "regnskap.inntekter"], ["dataModel", "regnskap.utgifter"] | ||
| ] |
There was a problem hiding this comment.
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.
| "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"]).
| 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 |
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
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.
Summary by CodeRabbit