Attributes Form issues with Joined Tables/Fields

[Saijin-Naib]

Describe the bug When a target layer which has has join(s) to other layers/tables with dynamic form, editiable join, upset on edit, and delete cascade enabled as well as an Attributes Form which exposes the joined fields, the joined fields are not editable, nor is the joined layer/table made editable when the primary layer (containing the Attributes Form) is made editable.

How to Reproduce Have a layer with join Have join settings as below Note that widgets for joined fields are not able to be made editable Enable edit on the layer with the form, note that widgets for joined fields are not editable/enabled

QGIS and OS versions

QGIS version	3.10.0-A Coruña	QGIS code revision	6ffa89eb3e
Compiled against Qt	5.11.2	Running against Qt	5.11.2
Compiled against GDAL/OGR	3.0.2	Running against GDAL/OGR	3.0.2
Compiled against GEOS	3.8.0-CAPI-1.13.1	Running against GEOS	3.8.0-CAPI-1.13.1
Compiled against SQLite	3.29.0	Running against SQLite	3.29.0
PostgreSQL Client Version	11.5	SpatiaLite Version	4.3.0
QWT Version	6.1.3	QScintilla2 Version	2.10.8
Compiled against PROJ	6.2.1	Running against PROJ	Rel. 6.2.1, November 1st, 2019
OS Version	Windows 10 (10.0)
Active python plugins	amaps; AppendFeaturesToLayer; batch_hillshader-master; BoundaryDelineation; BufferByPercentage; CalculateGeometry; cartogram3; changeDataSource; contour; DataPlotly; DEMto3D; disconnected-islands; dzetsaka; FeatureGridCreator; geocatbridge; GeoCoding; GeodesicDensifier; geomovetools; getools; GroupPointsWithinDistance; guided_offline_editing; HCMGIS; htpgeoprocessor; joinmultiplelines; karika; kmltools; kml_style_importer; LandSurveyCodesImport; LAStools; latlontools; LineDirectionHistogram; lrs; maps2winbugs; MemoryLayerSaver; minimum_spanning_tree; mmqgis; networks; openeo-qgis-plugin-master; ORStools; oscars-georaster-qgis-plugin; ParallelLineConstruction; pdaltools; PeliasGeocoding; photo2shape; Polygons_Pile; polystrip; processing_circuitscape; processing_fusion; processing_gnm; processing_js; processing_pktools; processing_prepair; processing_r; processing_saga; processing_saga_nextgen; processing_taudem; processing_trajectory; processing_whitebox; project_colors_dock; qchainage; qconsolidate; qdraw; qgiscloud; QgisModelBaker; QGISRed; QGISSortAndNumber-master; qgis_resource_sharing; qgSurf; QRectangleCreator; QuickOSM; quick_map_services; realcentroid; refFunctions; SelectWithin; SemiAutomaticClassificationPlugin; sen2cor_adapter; Serval; shapetools; snail; spatial_query_with_values; SplitPolygonShowingAreas; SpreadsheetLayers; statist; ThToolBox; toggle_labels_widget; trail_elevation_stats; vector_tiles_reader; wnt; db_manager; MetaSearch; processing

Additional context Having the Attributes Form behave differently than the join would indicate is confusing, and counter-intuitive. One would expect that by setting those options on the join and exposing the fields in the UI that they would be editable.

[gioman]

Having the Attributes Form behave differently than the join would indicate is confusing, and counter-intuitive. One would expect that by setting those options on the join and exposing the fields in the UI that they would be editable.

agree

[roya0045]

Having the Attributes Form behave differently than the join would indicate is confusing, and counter-intuitive. One would expect that by setting those options on the join and exposing the fields in the UI that they would be editable.

agree

I doubt this is desirable though. I agree that a change might be needed in editing mode but letting a user edit or even delete information on another source that is joined is a bad idea.

The external source should only be editable by itself and not through a join, otherwise this is asking for the impossible and is a huge cause for potential issue.

Maybe the options should be renamed or better documented if they lead to confusion.

[Saijin-Naib]

Then as implemented, the attribute forms are not terribly useful, to be frank.

The whole point, as I understand it, is to enable a user-friendly GUI to input data. If you're normalizing your data(base), you will by definition have multiple joins against a given dataset. To expect a user who is meant to only interact with the data through your GUI point&click form to know what all layers need to be put into edit mode and how that cascades through the joins misses the entire benefit of this type of UI/UX.

By making use of the UI in the Attribute Forms, you're abstracting away the user's access to the underlying data itself, and can do really neat things to ensure data integrity via setting valid values, ranges, etc. If you only show the user this UI, they can't do anything you don't have exposed via the Attributes Form UI, so the risk of data loss should be nil. Furthermore, these constraints apply directly to the Attributes Table data entry as well, so even if they got squirrely and went into the table, the constraints you setup on the given field in the form supersede manual direct entry of data into that field, thus protecting it.

[gioman]

I agree that a change might be needed in editing mode but letting a user edit or even delete information on another source that is joined is a bad idea.

why? If I have write access to a datasource (be it in a database or a local/network drive) why I should be afraid of edit it while in a join? I understand this could be a technically hard feature to implement(?) but I don't see how this could not be desirable.

By the way this should be changed to feature request.

[roya0045]

@gioman For some basic cases when the file are read only or when qgis cannot edit them (such as csv) this makes things harder to deal with. If you have write access then yes it should be fine but how should it deal with unjoined features when you alter the whole column, etc.

It should be possible but quite hard to implement properly.

[Saijin-Naib]

@gioman For some basic cases when the file are read only or when qgis cannot edit them (such as csv) this makes things harder to deal with. If you have write access then yes it should be fine but how should it deal with unjoined features when you alter the whole column, etc. It should be possible but quite hard to implement properly.

These are already existing problems with how the feature Joins and Relations are implemented, though, aren't they?

[elpaso]

To expect a user who is meant to only interact with the data through your GUI point&click form to know what all layers need to be put into edit mode and how that cascades through the joins misses the entire benefit of this type of UI/UX.

You can use transaction groups with DB backends that supports them for switch editing on/off on a group of layers.

On a more general note, I think that given the variety of data sources that QGIS can handle we cannot expect any strict relation integrity checking and automatic GUI relation handling in the foreseeable future.

That said, the current situation is far from ideal, there are quite a few not perfectly integrated pieces that provide join/relation management and data entry/validation, but they are available in different GUI context and sometimes not even fully implemented (see the lack of relation editing).

One of the reasons of the missing integration is that QGIS huge varieties of data sources requires a flexible atomic approach for capabilities supported by the different providers but there we are also facing a few design issues due to the different times/developers/goals that were involved in the development.

[nyalldawson]

I think this is "just" a bug -- editing join layers works fine in some circumstances, eg editing auxillary fields is fine in both attribute table and form more

[Saijin-Naib]

You can use transaction groups with DB backends that supports them for switch editing on/off on a group of layers.

Understood. I'll see about trying to enforce that for the time being on the GPKG datastore. This definitely sounds like a deficiency on my end in regards to database management.

On a more general note, I think that given the variety of data sources that QGIS can handle we cannot expect any strict relation integrity checking and automatic GUI relation handling in the foreseeable future.

That sounds fair.

That said, the current situation is far from ideal, there are quite a few not perfectly integrated pieces that provide join/relation management and data entry/validation, but they are available in different GUI context and sometimes not even fully implemented (see the lack of relation editing). One of the reasons of the missing integration is that QGIS huge varieties of data sources requires a flexible atomic approach for capabilities supported by the different providers but there we are also facing a few design issues due to the different times/developers/goals that were involved in the development.

That makes sense. QGIS is a huge project that subsumes other huge projects... I know I'm pointing out a large number of things, but it isn't anything malicious and I don't mean to pester. From my prior understanding, what I was observing felt like a bug. With the new context, I see it is just a missing feature/implementation.

I think this is "just" a bug -- editing join layers works fine in some circumstances, eg editing auxillary fields is fine in both attribute table and form more

If that's the case, it is likely a fairly big one to squish, correct? A lot of systems seem to be involved here.

[pedrogeo]

Hi,

I have the same problem with layers in a geopackage with the same settings which are in the first screenshot of Saijin-Naib. Joined fields are not editable. I'm on Qgis 3.10.1, Windows 10.

Same behaviour on Qgis 3.4.14.

Pierre

[Pedro-Murteira]

@Saijin-Naib Hello, is this one still valid on recent versions?

[github-actions[bot]]

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale". If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue. In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue. If there is no further activity on this issue, it will be closed in a week.

[Saijin-Naib]

Still valid, unfortunately.