Multi-edit behaviour causing data loss with default value calculations

[she-weeds]

What is the bug or the crash? What were your expectations and what actually happened?

I have merged three issues into one because I think they are closely related - please let me know if I should split them off. These all have to do with multi-edit mode and fields with default value calculations ("output fields"), that rely on other fields ("input fields"). Crucially, these problems occur when the features have different values between them for the fields (whether input or output) - therefore the field shows Value skipped (click to toggle).

Issue 1 - Default values erased when no changes committed whatsoever

With multiple features in edit mode, if you make no changes, and exit editing mode by clicking on the tick or the cross button, if there were output fields with different default values between features, they are erased (or, if the expression has a null handler using coalesce(), it will be the resulting non-null value). However, all input fields remain the same.

The expected behaviour is that the default values in the output fields should stay the same if there are no edits to the features whatsoever triggering an update.

Issue 2 - All default values erased when changes committed in unrelated fields

Same as issue 2, except this happens when a change is made in an unrelated field. This includes fields that are not an input/output field (e.g., text in the sample project).

The expected behaviour is that the default values in the output fields should stay the same if there are no changes to the input fields they rely on.

Issue 3 - When one input field value is changed, output field default value behaviour is inconsistently applied only to first feature

I have tested with two kinds of input/output pairs:
Simple : calculation from other field in same layer, no other layers involved.
Not-simple: calculation from other field in same layer, which is used to look up a value in another layer

The expected behaviour is that in multi-edit mode, if the input field values (and corresponding output values) are different between features, if you then update the input field values to be the same for all features (triggering the input field to show Value applied), the output field values should be (a) re-calculated (as seen on the form), and (b) applied to all features, without having to toggle anything else.

This works correctly for "simple" output fields without having to manually toggle the output field to Value applied, and irrespective of values in other fields.

However, part (b) seems to be inconsistent for "not-simple" output fields. If there are other input/output pairs that have different values between features, not only will those default values be borked regardless (see Issue 2), but for the output field you actually wanted to change, even though you see the updated value on the form (part (a)), only the first feature will have it. It is null or equivalent for the rest.
It is sometimes possible to get around this by toggling 'Value applied' in the output field, but only before changing the input values??

Needless to say it is wreaking minor havoc in the field as we have numerous auto-calc fields (for example, many trees with different stem diameters and protection zones, but we want to change them all to one species and corresponding common name - not only is the updated common name limited to the first feature, but all the protection zones and other auto calculated fields are erased).

It does not seem to matter if the output field has 'editable' or 'reuse last value' toggled in QGIS so I don't think it is an issue there.

Steps to reproduce the issue

Please see sample project - qfield multi calc test.zip

There are two pairs of input/output default values:
a. species (input) feeds into common_name (output), by doing a lookup of input values in layer list - this is the "not-simple" field
b. stem_diameter (input) feeds into protection_zone (output, nrz) - this is the "simple" field

Issue 1

1. Digitise two features: species = Araucaria for one, and Betula for the other. Keep stem_diameter = 45 and text can be whatever.
2. You should get common_name = hoop pine for the first feature and birch for the second feature. Both have a protection_zone value of 5.4m.
3. Select both features and enable multi-edit
4. Cancel multi-edit without any changes
5. You will now see that common_name of both features has been reset to null, although species is still the original value. Note that the protection_zone has not been reset as it (and stem_diameter) are the same in both features.

Example:

video_2026-03-21_17-14-43.mp4

You can repeat the above by having the same species but a different stem_diameter. Then you will see the protection_value has been reset to null in step 6.

Issue 2

1. Follow steps 1-3 of issue 1
2. In multi-edit, change text value to anything (doesn't matter if they were different or the same originally) and save the edits.
3. You should see the same result as step 6 of issue 1.

You can also get the same outcome if you change species or stem_diameter, but only if it was different originally.

Issue 3

1. Digitise two features: species = Araucaria and stem_diameter = 45 for one, and species = Betula and stem_diameter = 35 for the other. text can be whatever.
2. You should get common_name = hoop pine and protection_zone = 5.4 for the first feature and common_name = birch and protection_zone = 4.2 for the second feature.
3. Select both features and enable multi-edit
4. Change species = Carpinus. You will see, on the form, that common_name has been changed to hornbeam. Save the edits.
5. You will now see that common_name is hornbeam for feature 1, but it is a null value for feature 2. Aside from that, protection_zone has also been set to null.

Example:

video_2026-03-21_17-14-47.mp4

However, if you have the stem_diameter the same, common_name is updated correctly for both features.

Example:

video_2026-03-21_17-14-49.mp4

Version

4.1.0, 4.1.1, beta 7165 (1556aa0)

Operating system name

Android

Operating system version

16

Reinstall QField

• I have a fresh install of the latest QField version, but the problem persists.
• Problem can be reliably reproduced, doesn't happen randomly.
• Problem happens with all files and projects, not only some files or projects.

Additional context

I've run out of time to test properly on older versions but I'm positive this didn't used to be an issue in 3.7.9 and probably 4.0.x.

[nirvn]

@she-weeds , these should be fixed by this PR (#7167). APKs will appear in 15 minutes or so, confirmation that things are working as you'd expect will be most welcome :)

[she-weeds]

Hi @nirvn , can confirm the issue is fixed in 4.1.2, thank you so much!

[nirvn]

@she-weeds , thanks for your quality reporting