QWC2 offers comprehensive editing support through a variety of plugins:
Editingplugin allows creating, editing and removing features of an editable vector layer. It supports editing both geometry and attributes, displaying customizeable attribute forms.
AttributeTableplugin also allows creating, editing and removing features of an editable vector layer. It displays all features of the editable layer in a tabularized view, and allows editing attributes, but not geometries. Noteably, it will allow editing geometryless datasets.
FeatureFormworks similarly to the feature-info, but will display the feature form according to the QGIS form configuration, and also allows editing the attributes and geometry of a picked feature. It can configured as
identifyToolinstead of the standard
Quick start ¶
To make a layer editable, follow these steps:
- The datasource of the layer needs to be a PostGIS database. In particular, make sure that a primary key is configured for your dataset!
- Configure the QGIS PostgreSQL connection using a service name, add the corresponding service definition to your host
qwc-docker/pg_service-write.conf. Make sure your database host is reachable within the docker containers!
- Especially when your primary key field type is
serial, you'll want to mark the corresponding field widget type as
Hiddenin the QGIS Attributes Form settings.
- Create a
Dataresource as child of the corresponding
Mapresource in the administration backend, and create a new permission for the
Dataresources for the roles which should be allowed to edit the layer.
- Note: if you leave the "Write" checkbox in the
Dataresource permission unchecked, the dataset will be available as read-only, which can be useful if you want to use the
FeatureFormto just display the dataset without allowing any edits.
- Run the config generator from the administration backend to update service configuration.
Designing the edit forms¶
Much of the power of the QWC2 editing functionality resides in its fully customizeable forms, providing support for different input widget types, file uploads and 1:N relations.
qwc-config-generator will automatically generate forms based on the configuration specified in the QGIS Layer Properties → Attributes Form. If
Drag and Drop Designer is chosen, a corresponding Qt UI form is automatically generated for QWC2 in
Provide ui-file is chosen, the specified UI form will copied to
Localized translation forms are supported. To this end, place a Qt Translation file called
<form_basename>_<lang>.ts next to the designer form
lang is a language or language/country code, i.e.
en-US. There is a
translateui.sh script to help generate the translation files. Example:
./translateui.sh .../qwc2/assets/forms/form.ui de it fr
You can configure a text-like field of your dataset as an upload field as follows:
Drag and Drop Designerforms configuration, set the widget type to Attachment. You can set the file type filter in the widget configuration under
Display button to open file dialog -> Filter, in the format
- For manually created Qt Designed Ui forms, use a
<fieldname>__upload, and optionally as the text value of the
QLineEditset a comma separated list of suggested file extensions.
Attachments are stored on disk below the
attachments_base_dir defined in the data service configuration, and the path to the attachments stored in the dataset.
- If you set the format constraint to
*.jpegand your browser has access to a camera, QWC2 will allow you to directly upload images captured from the camera.
- You can set the allowed attachment extensions and maximum file sizes globally by setting
max_attachment_file_sizein the data service configuration. You may also need to set/increase
- You can also set the allowed attachment extensions and maximum file sizes per dataset by setting
allowed_extensions_per_datasetin the data service configuration. If you set the per dataset values, the global settings will be disregarded (i.e. if an attachment satisfies the per dataset constraint it will be considered valid, even if it violates the global constraint).
- To ensure the uploaded files are properly rendered as download links in GetFeatureInfo responses, use the
Key-value relations (value mappings)¶
Value relations allow mapping technical values to a human readable display strings, displayed in a combo box.
Drag and Drop Designer, use widgets of type
In a manually created Qt-Designer Ui form, you can use key-value relations for combo box entries by naming the
QComboBox widget according to the following pattern:
<kvtablename> refers to a table containing a field called
<kvtable_valuefield> for the value of the entry and a field
<kvtable_labelfield> for the label of the entry. For key-value relations inside a 1:N relation, use
Note: The relation table needs to be added as a (geometryless) table to the QGIS Project. You also need to set appropriate permissions for the relation table dataset in the QWC admin backend. Alternatively, you can set
true in the config generator configuration, to automatically generate resources and read-only permissions as required.
1:N relations allow associating multiple child records to the target feature, displayed in a table.
Drag and Drop Designer forms, configure the 1:N relation in QGIS Project → Properties → Relations. Note that the child table foreign key must refer to parent primary key.
By default, a table widget similar to an attribute table will be generated to manage the relation values. If you set
true in the config generator config, the relation values will be displayed as a list of buttons which open the record in a nested form. The button label is chosen according to the following rules:
- The display name (Layer properties → Display → Display Name) of the referencing layer, if the expression is a single field name.
- The primary key value of the referencing layer.
In a manually created Qt-Designer Ui form, create a widget of type
QFrame named according to the pattern
<reltablename> is the name of the relation table and
<foreignkeyfield> the name of the foreign key field in the relation table. Inside this widget, add the edit widgets for the values of the relation table. Name the widgets
<reltablename>__<fieldname>. These edit widgets will be replicated for each relation record.
- In a manually created Qt-Designer Ui form, you can also specify a sort column for the 1:N relation in the form
nrel__<reltablename>__<foreignkeyfield>__<sortcol>. If a sort-column is specified, QWC2 will display sort arrows for each entry in the relation widget.
- The relation table needs to be added as a (geometryless) table to the QGIS Project. You also need to set appropriate permissions for the relation table dataset in the QWC admin backend.
Special form widgets¶
In manually created Qt-Designer Ui forms, there are a number of special widgets you can use:
- Images: To display attribute values which contain an image URL as an inline image, use a
- Linked features: To display a button to choose a linked feature and edit its attributes in a nested edit form, create a
featurelink__<linkdataset>__<fieldname>(simple join) or
featurelink__<linkdataset>__<reltable>__<fieldname>in a 1:N relation. In a 1:N relation,
linkdatasetcan be equal to
reltableto edit the relation record itself in the nested form.
fieldnamewill contain the
idof the linked feature.
- External fields: Some times it is useful to display information from an external source in the edit form. This can be accomplished by creating a
ext__<fieldname>and using a form preprocessor hook (see
QtDesignerForm.jsxto populate the field by assigning a React fragment to
- Buttons: To add a button with a custom action, add a
btn__<buttonname>, and use a form preprocessor hook to set the custom function to
qwc-data-service offers some basic functionality for logging mutations:
- If you set
upload_user_field_suffixin the data service config, the username of the last user who performed a mutation to
<fieldname>will be logged to
- If you set
edit_user_fieldin the data service config, the username of the last user who performed a mutation to a record with be logged to the
<edit_user_field>field of the record.
- If you set
edit_timestamp_fieldin the data service config, the timestamp of the last mutation to a record will be logged to the
<edit_timestamp_field>field of the record.
Note: for these fields to be written, ensure the qgis project is also up-to-date, i.e. that contain the up-to-date table schemas. You can set the respective field types to hidden in the QGIS layer properties to avoid them showing up in the autogenerated edit forms.
Using a custom editing backend¶
You can also use a custom editing backend instead of the
qwc-data-service by following these steps:
- Implement the custom editing interface, taking default
EditingInterface.jsas a template.
- Enable the desired editing plugins in
js/appConfig.js, passing your custom editing interface to
- Set up an editing backend.
- If you are using the
qwc-config-generator, the edit configuration will be automatically generated from the QGIS project. Otherwise, you need to write a custom
||A WMS layer ID. Should be a theme WMS layer name, to ensure the WMS is correctly refreshed.|
||The layer name to show in the selection combo box.|
||The name of the edit dataset passed to the editing interface.|
||The geometry type, either
||The ID of the field to use in the feature selection menu.|
||A list of different write permissions to specify rights and buttons.|
||A list of field definitions, for each exposed attribute.|
||The field ID.|
||The field name, as displayed in the editing form.|
||A field type. Either
||Constraints for the input field.|
||For regular HTML input types, the ReactJS API name of any applicable HTML input constraint, i.e.
||Optional, a QtDesigner UI file.|
- If you specify just
fields, a simple form is autogenerated based on the field definitions.
- Alternatively you can specify the URL to a Qt Designer UI form in
:/<path>to specify a path below the