[needs-docs]
In vector layer properties (only usefull for postgres datasources)
**in the rendering tab**
A "Refresh layer on notification" checkbox has been added to refresh layer
on provider notification.
For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients,
a refresh of the layer will occur.
If the "Only if message is" checkbox is checked, the notification will trigger the refresh only
if the message contend is the one specified, e.g. if the user enters
"refresh" in the box right next to the "Only if message is" checkbox,
then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger
a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';`
won't.
**in the actions tab**
A column "On notification" has been added, the action editor widget
a has text field "Execute if notification message matches" to
specify a filter for notification from the provider. The filter is a
Perl-type regex.
Note that, as opposed to the "layer refresh" that
Exemple:
- QGIS side "Execute if notification message matches" `^trigger my action`
- Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action
- Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action
- Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action
Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited,
the last notification would have triggered the action because the
notification message contains the `trigger my action`
A new qgis variable `notification_message` is available for use in
actions, it holds the contend of the notification message. To continue
with the previous exemple, if the action is of python type with the code:
```python
print('[% @notification_message %]')
```
The three notifictions above will result in two printed lines
```
trigger my action
trigger my action some additional data
```
User Warning:
For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has
"On notification" specified, a new connection to the database is made to
listen to postgres notifications. This olds even if transaction groups
are enabled at the project level.
Note that once the notification mechanism is started in a QGIS
session, it will not stop, even if there is no more need for it (Refresh
layer on notification" unchecked and no "On notification" in any
action). Consequently the connection listening to notification will
remain open.
IMPLEMENTATION DETAILS:
A notify signal has been added to the abstract QgsVectorDataProvider
along with a setListening function that enables/disble the notification
mechanism.
For the moment only the postgres provider implements the notification.
QgsAction has a notificationMessage member function that holds the regex
to match to trigger action
QgsActionManager becomes a QObject and is doing the filtering and execute actions on
notifications.
The notification notion extends beyond SRGBD servers (postgres and oracle at
least have the notify) and the "watch file" in the delimitedtext
provider could also benefit from this interface.
For the postgres provider a thread is created with a second connection
to the database. This thread is responsible for listening postgres
notifications.
It would be nice to avoid the creation of one listening chanel per
provider in the case transaction groups are enabled.
Please note that when listening starts (a thread and connection is
created in the postgres provider) it cannot be stopped by removing the
connected actions or unchecking the refresh check box. Indeed, since we
don't know who needs the signals, we dont't want to stop the service.
The service will not restart in the next qgis session though.
If this behavior is not deemed appropriate, we could use
```
int QObject::receivers ( const char * signal ) const
```
and have QgsDataProvider::setListening return a bool to tell the caller
if the signal has actually been closed.
Instead of showing the progress reports for each child algorithm
individually, which leads to repeated 0->100% progress for every
step of a model, we proxy the progress reports and account for the
overall progress through a model as well. This means that
the progress accounts for both the progress within the current
model step AND the total number of steps left to execute.
Currently most browser item actions are parented to the item
itself, which is often long-lived (e.g. connection items
which last for the duration of the qgis session). This
commit adds an explicit parent widget parameter to
QgsDataItem::actions to ensure that the newly created actions
are correctly parented to the menu, and deleted after the
menu is removed.
* [FEATURE] adds undo/redo for transaction groups
[needs-docs] the undo/redo now works with transcation groups. Just check
that there is no restriction in the transaction groups doc concerning
undo.
related to #14799
The undo/redo is implemented using SAVEPOINT.
The QgsTransaction interface has been enlarged to allow savepoints
creation and management. The savepoint is destroyed on
rollbackToSavepoint to have the same behavior has the sql ROLLBACK TO
SAVEPPOINT.
To avoid the creation of a savepoint for each feature modified in bulk
editing (e.g. paste, field calculator) the logic is a bit complicated: the
savepoint is created on QgsVectorLayer::editCommandStarted and the first
actual undo command (QgsVectorLayerUndoPassthroughCommand) is
responsible for the re-creation of the savepoint in case of undo-redo.
Since the behavior must be different in case edition doesn't take place
inside an edit command, a member function has been added to
QgsVectorLayer to expose the mEditCommandActive state.
Another (commented) tricky bit is the modification of the database
structure on add/delete attributes. On undo, the attribute is removed
before the rollback to savepoint, i.e. there is a useless ALTER TABLE
issued to restore the structure just before restoring it with the
ROLLBACK TO SAVEPOINT. This is necessary to make the provider
aware of the change of structure. It could be nicer/cleaner to have a way
to reload providers metadata.
The editPaste function has also been modified to use addFeatures instead of
addFeature (plural/singular), this is at the expense of an additional "cpy"
of the clipboard in memory, but it should improve perf with postgis provider.
* fixup operator aliases
In the style dock there is a new "3D View" tab - so far working just for polygon layers.
It is possible to select a polygon layer, enable 3D renderer and adjust its properties.
If a 3D Map View is open, it will be immediately updated (if auto-apply is enabled)
Very exciting! :-)
