Bug report #17712
When a default value is set on a layer, a new value cannot be entered
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Edit widget | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Debian 9.1 | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 25609 |
Description
Using the layer properties and going to Attributes Form and selecting a field that is type int with 4 digits maximum length and I want to have it default to 0 when the new record is added to the table. So I go down to Defaults and next to "Default Value" I put in 0
Now when the record is created it puts 0 into this field so there is not a null value in it if I don't type in anything.
But this prevents me from changing the value to something else. It just gets wiped and set back to the default
My understanding of a default from years of programming and DBMS is it is the value that gets put in when the record is created, but can be changed later.
If you want to have a field that contains a fixed value that can't be changed this is something else (the terminology from the programming I used to do was either "Locked" or "Read Only")
Associated revisions
Fix default value 'apply on update' setting not correctly restored
Fixes #17712
History
#1
Updated by Patrick Dunford over 6 years ago
This is actually a very tricky little problem.
Basically when it decides to enforce the default values is if you tick a box called "Apply default value on update". At that point the default are always enforced in the field.
I read this was something to do with getting a timestamp put into a field that always updates itself every time the record is saved but the wording could be a lot more meaningful.
The box unticks itself next time you open the Attributes form section of the properties so this option can't actually be turned off if you change your mind, unless you remove the default altogether.
In programming we call this a "calculated field" not a "default".
#2
Updated by Patrick Dunford over 6 years ago
This default thing is a crock, if I split a feature in two the second part is created with the default values, whereas the normal behaviour is that the second part will inherit the values of the part it was split from.
#3
Updated by Nathan Woodrow over 6 years ago
This is simply a bug with that check box. The default behaviour is correct from what I can see here. If set the default to 10 it is set to that when I open the form and I can change it. If you select Apply Default on Update then it should only set the new value when you save. That checkbox should really set the editable box to false so it's a read only field at that point.
#4
Updated by Matthias Kuhn over 6 years ago
Thank you for your bug report.
I read this was something to do with getting a timestamp put into a field that always updates itself every time the record is saved but the wording could be a lot more meaningful.
Do you have a suggestion?
#5
Updated by Matthias Kuhn over 6 years ago
- Status changed from Open to Feedback
#6
Updated by Patrick Dunford over 6 years ago
I guess that it revolves around what terminology "default" or "calculated" as suggested is the appropriate wording to use. I always have regarded a default as the value that will be entered in a field if you don't put a value in yourself, and is a way of making sure there are no nulls entered.
#7
Updated by Harrissou Santanna over 6 years ago
I think the idea behind this term is that the field would be populated by default, meaning that you can skip filling it manually.
Actually it's a default option (in the way you suggest it, Patrick) if you fill it with a value; you'd get the same value for each new feature you create. Nothing dynamic.
In case you use an expression, the value in the form can change. and i think it'd be a shame to not extend this field with QGIS expression power.
What's the vocabulary used for fields like primary key? It's almost the same behavior.
About the checkbox behavior, it's a bug: default should be deactivatable, modifiable, (un)enforcable....
#8
Updated by Nyall Dawson over 6 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset qgis|fe2292c59a5fb7c65399aaf8903e33dbe9ab41d4.
#9
Updated by Giovanni Manghi about 6 years ago
- Resolution set to fixed/implemented