[Bug]: Bad relationship value when creating a child from a parent (works well in QGIS)

[sigsdis30]

What is the bug?

When creating a child from a parent, the value entered from relationship reference or relationship value is not the parent value.

Parent table: "pistes" with id serial and code_de_la_piste (unique in the table. Examples: U18_1CG, U18_2CG)
Child table: "controles" with id serial and code_de_la_piste
Relation 1:M between these tables on code_de_la_piste column
relationship_value.pdf

Steps to reproduce the issue

In lizmap:

1. Click on "piste" U18_1CG and edit
2. Add an child: the "code_de_la_piste" value isn't U18_1CG but U18_2CG that is the code of another piste (with the same code beginning)

In QGIS project, it works well

Lizmap version

3.4.8

QGIS desktop version

3.16.4

QGIS server version

3.16.8

Operating system

Windows 10

Browsers

Chrome

Browsers version

96.0.4664.110

Relevant log output

No response

[mdouchin]

We have reproduced this issue too. I will propose a fix ASAP

[sigsdis30]

Thank you!

[sigsdis30]

Have you made any progress on fixing this bug?

After our first post, we filtered the problematic rows in the table but another problem occurs with WFS: "Lizmap ne peut pas récupérer cet objet via le WFS". We probably made a mistake leaving two layers with the same name (?). We have therefore completely recreated our data structure (schema, tables, views...) as well as the lizmap map. In the new one, it's even worse: almost all objects get wrong parent values !

We plan to hide the map so that it is no longer accessible to users. Without it, they will insert wrong data into the database.

[mdouchin]

Sorry for the delay, I am working on it, and plan to release a fix before this weekend.

[sigsdis30]

If it can be useful, we make a few observations. We mainly work on two layers: water points (points) and tracks (lines). In both cases, these are views whose identifier is calculated with row_number().
In our production map, the problem only occurs on the tracks. In the new map, it only occurs on water points. In both cases, the problem is related to a bad identifier referenced in the code. The issue #235 helped us understand.
For example:
<a class="lizmap-atlasprint-link" data-href="/30/index.php/lizmap/service/?repository=controledfci&amp;project=controle_dfci&amp;SERVICE=WMS&amp;VERSION=1.3.0&amp;REQUEST=GetPrintAtlas&amp;FORMAT=pdf&amp;EXCEPTIONS=application/vnd.ogc.se_inimage&amp;TRANSPARENT=true&amp;DPI=100&amp;TEMPLATE=Fiche point d'eau&amp;LAYER=point_d_eau_dfci_a_controler_v_&amp;EXP_FILTER=$id IN (14)" href="/30/index.php/lizmap/service/?repository=controledfci&amp;project=controle_dfci&amp;SERVICE=WMS&amp;VERSION=1.3.0&amp;REQUEST=GetPrintAtlas&amp;FORMAT=pdf&amp;EXCEPTIONS=application/vnd.ogc.se_inimage&amp;TRANSPARENT=true&amp;DPI=100&amp;TEMPLATE=Fiche point d'eau&amp;LAYER=point_d_eau_dfci_a_controler_v_&amp;EXP_FILTER=$id IN (14)" target="_blank" title="" data-original-title="Exporter Fiche point d'eau"><span class="icon"></span>Fiche point d'eau</a>
EXP_FILTER = $ id IN (14) refers to the identifier 14 while the object has the identifier 94 in the database.

This problem probably explains two concomitant issues we encountered while clicking on certain objects with a user account with restricted access to layers:

• a WFS error
• the absence of the edit button
  The wrong identifier corresponds to an object that the user doesn't have the right to display or edit.

So, the problem doesn't seem directly related to the parent-child relationship but to the identifier retrieved by Lizmap. We are aware that the identifier used is not stable and could cause this problem as soon as a new object is inserted in one of the original tables, foreign tables that we do not administer in our case. But we don't think we can do otherwise with tracks, because the view aggregates the geometries of elementary objects and causes us to lose the primary key.

[sigsdis30]

Is the fix only for version 3.4.9? Our platform has been migrated to 3.5.0 and we still have the problem.

[sigsdis30]

Can you answer my previous question please? I'd like to know if I need to do something on my map or if I have to wait. Thank you.

[mdouchin]

Fix has been made in "master" then backported to the branches release_3_4 and release_3_5. The fix #2695 will indeed land in the future 3.4.9 and 3.5.1

Note: We have not tested if this fix will help for views using row_number()

[mdouchin]

The previously mentioned fix #2695 was not for this issue, sorry for this misunderstanding.

About this precise topic, QGIS Server cannot have a robust ID for this type if views using a row_number, so Lizmap cannot be sure that the data received from one instance of QGIS Server project will give the same ID as another requests. This leads to this issues you encounter, that we can not fix.

In the desktop QGIS environment, only one QGIS makes the requests, so in you work session, the ids are robusts when QGIS queries the whole dataset.
In the server environment, multiple QGIS Server are run in parallel, and each instance can have different ids for the same objects (depending on the order of reception of the data sent by PostgreSQL, which may vary depending on the number of features)

In Lizmap Web Client, for some features, such as a the selection, or a filter (by polygon, by login, or with the map tools), we ask only for an extract of the whole data from QGIS, for example only 10 lines. Each of these lines would have an id between 1 and 10 if you use row_number(), which will not correspond to the id of the layers objects when all the lines are requested.

I will contact you by email to give you more details and how you could improve your workflow in your specific context.

[sigsdis30]

OK, thank you.

[meyerlor]

Uhm, not sure if i should open another bug report, but creating a child feature from the parent's pop-up does not fill a value in the foreign-key field of the child, therefore a feature is created but it is not linked to the parent (or to anything at all). I have not a setup where i use postgres views or anything like that, just a plain and simple 1:n relationship where both layers are editable.

Isn't it very much the point of adding a child via the parent to have that child linked to the parent? Or is my setup somehow flawed?

I'm using LWC 3.8.3

Edit: After a lot of testing, i think to have found the culprit: The relationship field (foreign key) of the child feature needs to be visible in the form! If it is hidden (via QGIS Attriibute form layout), it is not working.