QEP 37: Allow simultaneous editing of attributes for multiple features through the attribute table “form” view

[nyalldawson]

QGIS Enhancement 37: Allow simultaneous editing of attributes for multiple features through the attribute table “form” view

Date 2016-03-16 Author Nyall Dawson (@nyalldawson) Contact nyall dot dawson at gmail dot com Status Accepted Funding Kanton Basel Stadt in Switzerland Version QGIS 2.16

Summary

Currently, QGIS attribute form only supports graphical editing of the attributes for one feature at a time. There is no way to set the attributes for multiple features at once through the form view. Limited editing for multiple features can be achieved using the “merge selected feature attributes” tool, but this tool is geared toward statistical calculation for multiple feature attributes and it is cumbersome to edit large amounts of attributes using this tool. Furthermore, the tool only provides for simple “text entry” of attributes, and cannot be used with all the advanced editor widgets which are possible to use in QGIS attribute forms (eg date/time widgets, relation widgets, unique value widgets, etc).

This QEP covers modifications to the attribute form and editor widgets to allow for simultaneously editing multiple features through the attribute form.

Relation to upcoming form search changes

Possible follow up work involves allowing the attribute form (including editor widgets) to be used for setting the parameters for searching and filtering layers. This QEP has been designed to allow this possible future work to hook in to the changes required for multi attribute editing.

Proposed Solution

Multiedit mode is initiated from the attribute form dialog through a new “Multiedit” button on the attribute table toolbar. It will work on selections made through the general QGIS feature selection tools or through the feature selection list shown on the left when in attribute form mode.

When multi-edit mode is activated, QGIS will scan all selected feature to determine whether each feature holds different values for a given attribute or whether all features have the same value. If an attribute holds mixed values across the selection, the widgets will be update to reflect this. For widget types where it is applicable (Eg text edits), the initial value for the widget will be set to “mixed values”. Other widget types may indicate this state in different ways, eg for checkbox widgets the mixed values state will be indicated by the “partially checked” state. This will not be possible for all widget types, eg sliders and dials. For these widgets the value from the first selected feature will be shown instead.

For all widget types, when in multi-edit mode, a tool button with icon will be shown to the right of the widget. Initially, the button will show an icon indicating whether the selection has mixed values for the field (possibly the mathematical “not equal” symbol). If the field does not have mixed values, a tick icon will be shown instead. When the field has mixed values in the selection, clicking the button will show a popup-menu with a single action “Set [field name] for all selected features”. Activating this action will force the field value for all selected features to match the current widget value.

When the value for a widget is changed, the icon next to the widget will change to a “!” alert icon. The tooltip for this icon will show “Value for [field name] for all selected features will be overridden”. Clicking the button when in this state will show a popup menu with a single item “Reset to original values”. Read-only widgets will stay disabled in the form and will never be changed. These widgets will either be shown in their “mixed value” state, or the value for the first selected feature if no mixed-state exists.

When saving multi-edits, only attributes that have a changed widget state (“!” icon) will be applied. Attributes which remain at their mixed value state will not be altered. Before applying the new attributes for all selected records the user has to confirm that they really want to change the attributes for all selected records and changed widgets.

All changes will be applied as a single edit command, so pressing undo will revert all changes made to all selected features at once.

The attribute table section (left panel) of the dual-view dialog will be active while multi-editing features. If the selection changes, the user will be prompted to save any current changes made to the previous selection.

Multi-edit mode will only be enabled for auto-generated and drag and drop forms. Custom forms will not be supported, due to the extra complexity added by custom layouts and python logic which could be present in these forms.

“Relation reference” widgets will be editable in multi-edit mode, however “relation editor widgets” will NOT be editable whilst in multi-edit mode.

Affected classes

• QgsDualView: will be modified to add a new multi edit toggle button and the corresponding signals/slots for enabling and triggering this button
• QgsEditorWidgetWrapper: a new virtual void setMixedState( bool mixed ) method will be added. The base implementation of this method will have no effect. QgsEditorWidgetWrapper subclasses can override this method to change their widget states to a "mixed value" state (eg QgsCheckboxWidgetWrapper will set its QCheckBox to the Qt::PartiallyChecked state). Other editor widgets will be updated to implement this method were appropriate (eg QgsTextEditWrapper, QgsClassificationWidgetWrapper, ... )
• QgsMultiEditToolButton: new QToolButton subclass for a widget which displays the state of an editor widget in multi edit mode. Eg shows the mixed values and changed values icons, and provides GUI to reset values to their original state.
• QgsAttributeForm: a new private method scanForEqualAttributes will be added, which will scan through a QgsFeatureIterator and return lists of both fields with mixed values and fields which all share the same values.
• QgsAttributeForm: a new enum will be added with corresponding getters and setters for setting the attribute form "mode". Options will include "SingleEditMode" (default, current behaviour) and "MultiEditMode". In future this will be extended to add "SearchMode".
• QgsAttributeFormEditorWidget: new QWidget subclass consisting of both an editor widget and additional widgets for controlling the behaviour of the editor widget depending on a number of possible modes. For instance, if the parent attribute form is in the multi edit mode, this widget will show both the editor widget and a tool button for controlling the multi edit results. (In future, when search mode is added, this widget will show the editor widget and a tool button for controlling search behaviour). Initially only DefaultMode (current behaviour - only the editor widget is shown) and MultiEditMode will be implemented. QgsAttributeFormEditorWidget will also have a method setIsMixed( bool mixed ), which if set will put both the editor widget and the multi edit button into the mixed values state.

  Tests

Tests will be added for the non-GUI portions of this QEP (eg QgsAttributeForm::scanForEqualAttributes). Additionally, tests will be added for checking the logic of the QgsMultiEditToolButton modes.

Votes

(required)

[bstroebl]

Before applying the new attributes for all selected records the user has to confirm that they really want to change the attributes for all selected records and changed widgets.

I would vote for skipping that altogether. For advanced users it is tideous to confirm what they already confirmed by clicking OK and others might not even read/understand. Besides there is still the undo button, maybe an information or warning is more adequate (which might be ignored by most users anyways :)

For all widget types, when in multi-edit mode, a tool button with icon will be shown to the right of the widget. Initially, the button will show an icon indicating whether the selection has mixed values for the field (possibly the mathematical “not equal” symbol). If the field does not have mixed values, a tick icon will be shown instead. When the field has mixed values in the selection, clicking the button will show a popup-menu with a single action “Set [field name] for all selected features”. Activating this action will force the field value for all selected features to match the current widget value.

Probably all widgets should be handled similar, i.e. show the first value in all and use an icon that clearly shows the mixed state (anything more straightforward than != which is normally unknown to all non-programmers). Editing by clicking on the button seems counterintuitive to me. IMHO editing should be just the same as in single-edit mode, e.g. changing whichever text is in the widget changes this attribute for all selected features; good idea to have icon indicate that changes have been made, though.

[elpaso]

Nice additions. Since you are still planning, is it possible to add the current form values to the (expression) context? This would make it possible not only dynamic filters on relation widgets but also to update fields dynamically when a values changes in another field.

[nyalldawson]

Before applying the new attributes for all selected records the user has to confirm that they really want to change the attributes for all selected records and changed widgets.

I would vote for skipping that altogether. For advanced users it is tideous to confirm what they already confirmed by clicking OK and others might not even read/understand. Besides there is still the undo button, maybe an information or warning is more adequate (which might be ignored by most users anyways :)

The issue is that if a user is unaware they are editing multiple features the changes may go unnoticed. For now we'll proceed with the confirmation prompt and if it proves annoying we can later revisit this.

For all widget types, when in multi-edit mode, a tool button with icon will be shown to the right of the widget. Initially, the button will show an icon indicating whether the selection has mixed values for the field (possibly the mathematical “not equal” symbol). If the field does not have mixed values, a tick icon will be shown instead. When the field has mixed values in the selection, clicking the button will show a popup-menu with a single action “Set [field name] for all selected features”. Activating this action will force the field value for all selected features to match the current widget value.

Probably all widgets should be handled similar, i.e. show the first value in all and use an icon that clearly shows the mixed state (anything more straightforward than != which is normally unknown to all non-programmers).

This is how it will work for widgets which don't have an obvious "mixed value" state. For widgets which do have mixed value states I think it's sensible to use them as it keeps consistency with the intended appearance/use with other applications in the same desktop environment.

I'll use the mathematical not equal to symbol "≠", not "!=".

Editing by clicking on the button seems counterintuitive to me. IMHO editing should be just the same as in single-edit mode, e.g. changing whichever text is in the widget changes this attribute for all selected features; good idea to have icon indicate that changes have been made, though.

That's how it will work. If you change the widget's value it will be applied to all selected features. You'd only ever need to use the menu in the state indicator button when a widget does not have a mixed value state. Eg, a dial cannot be set to no value, so it would show the value from the first selected feature. The only way to then set ALL features to this same value would be to either 1. change the widget and then change it back or 2. use the dropdown option from the state indicator button to force all selected features to take this same value.

[nyalldawson]

@elpaso

Since you are still planning, is it possible to add the current form values to the (expression) context? This would make it possible not only dynamic filters on relation widgets but also to update fields dynamically when a values changes in another field.

I'm afraid I don't understand. Are you referring to the multi edit described here or the future filtering use case? In any case the expression context will always have the current feature field values, so I'm still a bit lost.

[elpaso]

Sorry for not being clear, this is a more general topic that could impact your QEP or not. What I believe would be really useful in the form/attribute-table editing, is the possibility for an expression to access the current values of the widgets (before saving) . This is what my http://plugins.qgis.org/plugins/FormAwareValueRelationWidget/ does, with various degree of success and many hacks. When a user changes the value in a widget (before saving) an expression in another field could access all the current values of the current form or of the current row (in case of the attribute table). The other widgets could dynamically react to value changes in the other fields. This is currently not possible in table views, due to the editor widget being "deleteLater".

[bstroebl]

The issue is that if a user is unaware they are editing multiple features the changes may go unnoticed.

How can they be unaware when there is an icon next to each widget? If they are unaware then they would simply accept anything without reading/understanding the message (IMHO), so nothing gained.

For widgets which do have mixed value states I think it's sensible to use them as it keeps consistency with the intended appearance/use with other applications in the same desktop environment.

Sorry, I do not understand what you are thinking of here. Could you give an example? Anyway, I would prefer it to be consistent with QGIS' single-input mask. The message for all widgets would be the same: This is just some value in order to show one. Check the icon on the right if there are other values present. If you change this value, it is changed for all features, if you leave it untouched all features will stay as they are.

I'll use the mathematical not equal to symbol "≠", not "!=".

this is better, my misstake; probably show it on an alarm-colored ground (not sure if red is good because of red/green color-blinded, there might be UI guidelines covering that)

[m-kuhn]

If an attribute holds mixed values across the selection, the widgets will be update to reflect this. For widget types where it is applicable (Eg text edits), the initial value for the widget will be set to “mixed values”.

I'd just leave it empty or use grayed out, unselectable default placeholder text.

When the field has mixed values in the selection, clicking the button will show a popup-menu with a single action “Set [field name] for all selected features”. Activating this action will force the field value for all selected features to match the current widget value.

Just to be sure, it's not mandatory to use this button. A value can also just be changed for a mixed field and the state will be changed to "overwrite"?

Multi-edit mode will only be enabled for auto-generated and drag and drop forms. Custom forms will not be supported, due to the extra complexity added by custom layouts and python logic which could be present in these forms.

Python-logic is not bound to .ui, so it will have to be dealt with. I would activate python as normal, but send a signal and set a property for the logic to react/detect the multiedit mode.

“Relation reference” widgets will be editable in multi-edit mode, however “relation editor widgets” will NOT be editable whilst in multi-edit mode.

:(

Nah, that's really a big task to tackle on itself, wise choice to leave it out for now.

Good job! Looking forward!

[SrNetoChan]

Hi @nyalldawson. This is great work! And I this is one of my "guilty" missing features from ArcGIS (But not withthe class that you are describing :)). Some comments based on my experience with it.

With this work we will have a multiedit button to access multiple features forms, but we still don't have a similar button to easily open a single feature form (for that you need to go to the attribute table, or the identify tool). But with the implementation of this work, if you only have one feature selected, you will open it's form. My point is, why call it MultiEdit, and not simply open feature(s) form, with all the functionally described here if the user selects more that one feature? A similar button could be available in the attribute table for fast access.

Besides (just for reference and not that we should be copycatl ArgGIS) when multiple features were selected there was a left tree panel would allows you to navigate trough each features form individually (and edit it) or select the tree root to edit multiple features).

Any way, quite excited to see this feature in QGIS.

[m-kuhn]

One question still:

Did you plan to synchronize the edit selection with the layers feature selection somehow?

[nyalldawson]

@elpaso

Sorry for not being clear, this is a more general topic that could impact your QEP or not. What I believe would be really useful in the form/attribute-table editing, is the possibility for an expression to access the current values of the widgets (before saving) . This is what my http://plugins.qgis.org/plugins/FormAwareValueRelationWidget/ does, with various degree of success and many hacks. When a user changes the value in a widget (before saving) an expression in another field could access all the current values of the current form or of the current row (in case of the attribute table). The other widgets could dynamically react to value changes in the other fields. This is currently not possible in table views, due to the editor widget being "deleteLater".

Sounds intriguing, but not in scope for this work.

[nyalldawson]

@bstroebl

How can they be unaware when there is an icon next to each widget? If they are unaware then they would simply accept anything without reading/understanding the message (IMHO), so nothing gained.

Like I said, we'll leave the confirmation prompt in for now to be safe, but if it proves annoying it will be simple to remove.

@bstroebl @m-kuhn

Sorry, I do not understand what you are thinking of here. Could you give an example? Anyway, I would prefer it to be consistent with QGIS' single-input mask. The message for all widgets would be the same: This is just some value in order to show one. Check the icon on the right if there are other values present. If you change this value, it is changed for all features, if you leave it untouched all features will stay as they are.

I'd just leave it empty or use grayed out, unselectable default placeholder text.

That's what I'm doing for now. For everything that CAN be cleared and shown empty we'll do that. For the handful of widgets which don't have an empty state (or native "mixed" state like checkboxes have) I'll show the first value. This will include the color button widget, date/editor and spin box/range widgets. I'll update the QEP to reflect this.

@m-kuhn

Just to be sure, it's not mandatory to use this button. A value can also just be changed for a mixed field and the state will be changed to "overwrite"?

Correct. Changing the widget will immediately set the field's state to overwrite.

@m-kuhn

I would activate python as normal, but send a signal and set a property for the logic to react/detect the multiedit mode.

Good idea. I'll add that to the QEP.

One question still: Did you plan to synchronize the edit selection with the layers feature selection somehow?

Yes, the multiedit mode will operate on the current selection (made through canvas, select by expression, etc). If the selection changes while there is unsaved changes in the multiedit form the user will be prompted to save them first. Otherwise the multiedit features are automatically synced if the layer selection changes.

[3nids]

@nyalldawson excellent draft! I have no restriction from what I read, I think you have the right picture!

[andreasneumann]

+1 to accept this QEP.

We really need this to more efficiently edit bulk data in QGIS.

[timlinux]

Just a comment from me that a proposal like this could really benefit from some simple wireframes to illustrate the concept. When written as text it is very information dense and probably not easy for most people to visualise how the user experience will change. Love the planned improvements as laid out here though :+1:

[NathanW2]

@m-kuhn You are the forms man do you +1 this? Will approve if so.

[m-kuhn]

+1 from me. The proposal looks good and the public and private discussions were convincing.