-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #51543 and make big forms more fluid by reducing calls to updateFieldDependencies #51836
Fix #51543 and make big forms more fluid by reducing calls to updateFieldDependencies #51836
Conversation
@domi4484 will this be backported to QGIS 3.28? This is a prio1 on our side, otherwise there's a no go on QGIS 3.28. |
I agree - it would be really important to get such form improvements into 3.28. But it will require lots of testing by users. Form code is a bit fragile .. |
This would be very welcome and almost mandatory for such kind of changes. |
@ponceta @andreasneumann from my point of view this pr is ready. If you could do some additional manual tests it would be very appreciated! |
@domi4484 - this is still in a separate PR and not yet in master - right? I can do some tests tonight. |
@andreasneumann yes it is not merged yet |
@domi4484 - I tested this PR. I can confirm that the forms feel a lot "snappier" when the forms are big and have a lot of default values with "Apply on update". Good Work. I can't tell for sure that there are no side effects but so far I haven't found any problems. It would be great if another person that has complex forms could test as well. Otherwise I am definitely interested to see this land in master and backported to the LTR version. |
@ponceta - do you have a chance to test this? I would really like to see this land in master, and then after quarantine in an upcoming 3.28 release. For us, it makes a HUGE difference in our complex forms. Before it was very slow - now instant. |
I never build a custom QGIS with a PR yet but I do agree with Andreas, this is a great improvement. |
@domi4484 Can you create an LTR PR for this? |
@signedav can you add the label for automatic backport? I don't have permissions for that |
Thank you a lot, that's a huge thing for us, tried today on QGIS 3.28.4-2 and it's working as expected! |
@ponceta - thank you for the feedback. No troubles or side-effects were observed? For me it is the same - quite a good improvement! |
Not yet at least! ;) |
Hi, So it would be very convenient for me, to have the behaviour of 'Always apply default values' while creating new features, but let the data untouched while refreshing the attribute table. |
Hi! So I agree, an "apply defaults only when inserting feature" option would be highly appreciated. |
@peterankowiak and @spacerat1 I'm not sure if I understand your requirement. What you wish is the "Apply default value on update" behavior (live update in the form) on creating features, but not on changing values on existing features? There is a clear bug #54446 (maybe introduced with this PR but not sure) that in the attribute table the values are updated with "Apply default value on update" even when no value changed (no update is performed). Maybe you would already have the needed behavior when this is fixed? |
Thanks for your reply @signedav ! I will try to explain using an example. I use QField to map birds as point features. The form has the following fields:
As I need to be quick in the field (like 3 seconds per entry), I usually only enter species and breeding status code when creating a record, and pre-fill the rest of the form with defaults, based on expressions applied to those two entries. E.g. if I select "territorial male" -> sex = male, number = 1, observation time = now() and duration = 1, as this is the most likely combination. If other values occur (e.g. multiple individuals, observation in the past), I change them manually. For such use cases, where somewhat complex features need to be updated frequently, it would be ideal to have an option to apply defaults on feature creation only, but not again when updating a feature. As I mentioned in my previous post, this worked for me with older QGIS / QField versions, but stopped working at some point in spring 2023 (Was it possibly unintended behavior? Could it somehow be related to #51543?). |
You have to note that this part of the implementation is in the GUI - means QGIS and QField have independent implementations. I think yes, what you require is to be able to apply this functionality on create feature only. Maybe you could make a feature request issue for that option. |
Thank you @signedav ! So if I understand you correctly, it would have to be a feature request for both QField and QGIS? As I recall, it used to work (for above use case, in both QField and QGIS) when entering an expression in the defaults field but leaving the "apply defaults on update" box unchecked. In the recent versions, I observe the following behavior: QGIS 3.34: QField 3.0: There might actually be a workaround using virtual fields:
|
As of the current implementation when creating a new feature the attribute form behaves as "Always apply default values" checkbox was activated for all default values. After this pr the checkbox will be respected even when creating new features.
Update default values only during setting the feature (or always if "Always apply default values" checkbox is checked)
updateFieldDependencies only when resetting the form. This should make working with big forms more fluid as it spares a lot of loops trough all fields. Small downside for an edge case: if the dependencies are changed (for example default value expression on children layer) when a form is open, that form will not reflect the changes until reopened.