Even when the model execution fails, store the child inputs and
results for all steps which successfully completed in the context.
This gives more debugging information to a user when a model fails,
because these values will now be reflected in the model designer
view for all steps which completed.
We now always call QgsProcessingAlgorithm::postProcess, even when
the algorithm fails for some reason (eg it raises an exception).
This ensures that the context cleanup logic in postProcess is
always run. Note that we still ONLY call an algorithm's specific
postProcessAlgorithm implementation for successful executions,
so the public facing API and behavior remains unchanged.
This is intented to provide a consistent handling of the cleanup
logic in postProcess, specifically to make sure that that the
context thread handling logic is triggered in all cases.
And transparently map requests for grass7 provider to grass provider
It's misleading putting an old version number in the provider name,
when this provider supports grass versions 8 +
Use the safer method of explicitly including the provider type
when storing layer sources to string in more places, which eg
fixes running the copied qgis_process string when a non gdal
layer source is used for a raster layer. Also fixes the same
situation when restoring an algorithm from the history log.
Fixes#54264
uses expressions for parameter values and contains variables
generated by another step in the model
We were showing links for these in the model designer so it
appeared as though the dependencies were there, but at actual
execution time there was nothing forcing the child which generated
the variable to be run before the child using the variable.
At model debug log level we'll show all the generic
logs for step preparation, inputs and outputs for every
child algorithm, including those which we normally skip
(eg raise warnings/outputs, string concatenation, etc).
This gives model designers more useful information to
debug their models.
Use this new log level when running models through the
model designer window.
This adds a new "Reorder Model Outputs" action to the model designer
menu (to accompany the existing "Reorder Model Inputs" action).
Selecting this option allows model creators to set a specific order
which the outputs from their model must use when loading the results
into a project. This gives the model creator a means of ensuring
that layers are logically ordered, eg placing a vector layer over
a raster layer and a point layer over a polygon layer.
Optionally, the model creator can also set a "Group name" for the
outputs. If this is specified then all outputs from the model will
be placed into a (newly created if necessary) layer tree group
with that name.
Sponsored by the QGIS Germany User Group
efficiently for many calls
Allows retrieval of some basic algorithm properties (display name,
icon) in an optimised way for many calls. (Avoiding multiple
expensive algorithmById lookups)
