a feature copy/paste sets a NULL field to its "default value" in a geopackage

[faridcher]

What is the bug or the crash?

A feature copy and paste should also carry over all attributes value but the process sets a NULL field value to its default value which is set in its layer Attribute Form.

Steps to reproduce the issue

use the sample labs layer and its apartment field as a basis; its widget type is set to Checkbox and its default value to true (Layer properties-Attribute Form). Use the only feature in the layer with apartment=NULL. Copy and paste this feature to observe that the apartment field value of the new feature is set to true instead of NULL.

Versions

Qgis 3.16.8
@gioman also tested with master

Additional context

sample geopackage data: test.zip
@gioman could not not replicate with a PostGIS layer.

[gioman]

Qgis 3.10.14

@faridcher this version is EOL, you must test on 3.16 or 3.20

A feature copy and paste

@faridcher are you copying/pasting within the same layer or between different ones?

[gioman]

Sorry I am testing in Debian unstable and cannot compile the dev

@faridcher 3.16 is the stable version, 3.10 is EOL.

[gioman]

I will verify with a later version if it is too much a hassle.

@faridcher could not, but you could attach a sample layer for examples, so we can test on the same data.

[gioman]

@faridcher works fine here on a PostGIS layer on QGIS master on Ubuntu 20.04.

[gioman]

I upgraded to 3.16 .8 and I hit another bug!

@faridcher another bug, another ticket ;)

[gioman]

check with the apartment field of the layer.

@faridcher yes confirmed.

[gioman]

A boolean field with NULL values is wrongly shown as false in the 'Attribute Table';

@faridcher what field in your sample?

[gioman]

@gioman the same apartment field

@faridcher that is an effect of the "boolean" widget, if you set the edit widget to "text edit" you'll see the NULL value.

[gioman]

a boolean field could also take NULL so I think the widget should render NULLs correctly, don't you think?

@faridcher yes makes sense, anyway file a separate ticket please.

[faridcher]

@gioman Could you please hide all of the outdated comments to keep the issue tidy for the prospective bug hunter? I updated the question to reflect the outcome of our discussion. thank you

[troopa81]

@faridcher It's because you have defined a default value in your attribute form appartement configuration. So when you copy the feature, appartement attribute is NULL, so QGIS considers it has to use the defined default value.

You could possibily argue that is not the expected behavior and the new feature should be identical to the copied one, but maybe other users would expect to use the default value on a NULL field. I think I would favor the first one.

It looks like it has been the matter of debate. @m-kuhn @elpaso Do you remember what was the outcome of the discussion about that?

I can propose a fix, if we agree that we don't evaluate default value when user copy-paste feature

[nyalldawson]

if we agree that we don't evaluate default value when user copy-paste feature

That would be a very bad idea -- default values are used in workflows to do things like set a "feature created" field, which MUST be done when pasting features.

[m-kuhn]

It looks like it has been the matter of debate. @m-kuhn @elpaso Do you remember what was the outcome of the discussion about that?

The discussion there was different "if qgis default value returns null should we fallback to provider default value".

That would be a very bad idea -- default values are used in workflows to do things like set a "feature created" field, which MUST be done when pasting features.

Does that work? If there is a feature with a created_date already set to a value and it's copy/pasted, the field will not be updated.
Or are you talking about: if there is a target layer B with a field f and a source layer A without this field, default values must be inserted for field f on pasting. That's a requirement I've seen often.

[faridcher]

You could possibly argue that is not the expected behavior and the new feature should be identical to the copied one, but maybe other users would expect to use the default value on a NULL field. I think I would favor the first one.

@Troopa I also favor the first one. As the name implies (copy/paste), the target feature in the target layer should be as similar as possible to the source feature even its date_created field. I often copy/paste a feature to only change a single attribute of the pasted feature; with the NULL fields being set to their defaults, I am further obliged to set them to NULL manually. The user always can use the Create Feature tool if they want the default values; they then may utilize Merge Feature Attributes tool to match certain attributes. Or they may force a default value expression by updating a feature assuming the Apply default value on update option is checked in Layer properties-Attributes Form.

Disabling the default values expression altogether might preclude @m-kuhn described scenario (pasting across layers):

if there is a target layer B with a field f and a source layer A without this field, default values must be inserted for field f on pasting. That's a requirement I've seen often.

So the ultimate solution could be: upon paste, evaluate all default values (only when pasting across layers) and then paste all attributes including NULLs from the source feature in the source layer.

@Troopa thank you for looking at this.