Default value with an expression and "apply on update"

[aliasatp]

What is the question?

Hi all, I'm using lizmap 3.5, I have a QGIS project with some expressions as default value for fields. Editing with Lizmap I realised that "apply on update" doesn't work. Instead virtual fields are calculated but not visible. Am I doing something wrong? Thanks

Versions

QGIS 3.22.10 QGIS server LTR 3.22 LIZMAP 3.5.1

Check Lizmap plugin

• [ ] I have done the step just before in the Lizmap QGIS desktop plugin before opening this ticket. Otherwise, my ticket is not considered valid and might get closed.

QGIS server version, only if the section above doesn't mention the QGIS Server version

3.22.9

Operating system

WINDOWS SERVER R12

Browsers

Firefox

Browsers version

FIREFOX 104.0.2

Relevant log output

No response

[3liz-bot]

Hiya! This issue has gone quiet. 👻 We get a few questions in the bug tracker, we are currently slowly closing issues. If we missed this issue or if you want to keep it open, please reply here. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Thanks for being a part of the Lizmap community! 🦎

[Gustry]

The expression for default value only works for new objects. It's not yet supported for editing an existing object.

Let us know if you are really interested. As far as I can remember, it were some technical limitations.

[josemvm]

The expression for default value only works for new objects.

the expression for default value doesn't work for new objects on lwc 3.6(.4)

[Gustry]

the expression for default value doesn't work for new objects on lwc 3.6(.4)

it depends also on the expression used it self : does it need the current geom ? does it need a previous field from the form ? Even me, I don't know which use cases. For sure, the easiest expression having a single value, like @lizmap_user or now() works for instance.

[gioman]

it depends also on the expression used it self : does it need geom ? does it need a previous field from the form ?

@Gustry for expression involving geometries (example from point fill X and Y values in the table) would not be enough to force users to first draw/edit the geometry and then allow them fill the attributes?

Having expression that fill a field based on the content of another field in the same form is simply impossible to obtain in LMWC or "just" hard to implement?

[mdouchin]

It is already possible to set the filter of a combobox based on the drawn or modified geometry. This show that using an expression (filter or the value relation based combobox) is working. We should audit the JS code, and see if we can implement the default value, not only after the opening of the form, but also after the geometry have been drawn if the field is empty

[Gustry]

In Lizmap Web Client, the form is opened before we draw the geometry. In QGIS, from the main dialog, it's the reverse : we draw, then we have the form. Except when we do from the attribute table dialog, but then it's not possible to draw a geometry after.

For "default values" only, we need to write down the different context :

• Expressions which can be fully evaluated before displaying the form (and must be, to nform the user, like now(), @lizmap_user etc) <= The easy use-case are already supported
• Expressions which can be only evaluated after
  • One or many fields lost the focus (according to what the expression needs)
  • The geometry is drawn
  • A mix of the two
• Expressions which can be evaluated when we close the form

As @mdouchin said, a audit of the different context must be done.

This might vary between creation and editing with "Apply on update" ?

Value relation widget which are filtering by geometry after the geometry is drawn is already working for instance, see https://demo.snap.lizmap.com/lizmap_3_6/index.php/view/map?repository=testsrepository&project=form_edition_value_relation_field about "Geom expression" field.

PS 1 : On QGIS server, you should see requests coming for evaluating expressions, like SERVICE=EXPRESSION, you can see which expressions are evaluated for default values, like #3713

PS 2 : I know it's more complicated, but in the meantime, there are some PG triggers which are possible and working well. It's not the same use case, but it's a workaround.

[gioman]

As @mdouchin said, a audit of the different context must be done.

@Gustry @mdouchin thanks. As explained by email privately in the past weeks I would look favorably a sort of meeting where you (3liz) could let us (final users) know about the roadmap, what is already planned to be implemented, what not, what are your thoughts about some features being requested, ways of funding/supporting their implementation, etc.

[meyerlor]

I very much support what @gioman suggested - a roadmap would be very nice as well as your thoughts towards certain feature requests - like this here, which is kind of a "core" functionality of QGIS

(came here because i was trying without success to get a default picture name when uploading pics...)