lizmap-web-client
lizmap-web-client copied to clipboard
3liz
[Bug]: Bad relationship value when creating a child from a parent (works well in QGIS)
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:
- Click on "piste" U18_1CG and edit
- 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
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.
Sorry for the delay, I am working on it, and plan to release a fix before this weekend.
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&project=controle_dfci&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetPrintAtlas&FORMAT=pdf&EXCEPTIONS=application/vnd.ogc.se_inimage&TRANSPARENT=true&DPI=100&TEMPLATE=Fiche point d'eau&LAYER=point_d_eau_dfci_a_controler_v_&EXP_FILTER=$id IN (14)" href="/30/index.php/lizmap/service/?repository=controledfci&project=controle_dfci&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetPrintAtlas&FORMAT=pdf&EXCEPTIONS=application/vnd.ogc.se_inimage&TRANSPARENT=true&DPI=100&TEMPLATE=Fiche point d'eau&LAYER=point_d_eau_dfci_a_controler_v_&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.
Is the fix only for version 3.4.9? Our platform has been migrated to 3.5.0 and we still have the problem.
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.
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()
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.