This action shows the log of that child step, regardless of whether
or not it failed. This is handy for debugging model errors after
testing, when you've already closed the algorithm window...!
When editing a model through the designer (and after having run
that model), you can now right click any child step in the model
and select "View Output Layers". This will add the output layers
from that step as new layers in the current QGIS project.
This action is available for ALL child algorithms in the model,
even if the model is not configured to use the outputs from those
children as model outputs.
This is designed as a helpful debugging action. If a user's model
fails (or gives unexpected results), they can then trace through
the model and view the outputs for suspected problematic steps.
It avoids the need to add temporary outputs to a model and re-run
to test.
Additionally, this action is always available after running the model,
EVEN if the model itself failed (eg because of a misconfigured
step later in the model).
Sponsored by City of Canning
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.
Eg server layer title, abstract, etc, and deprecate the related
methods at the QgsMapLayer level
This should avoid accidental creep of these specifically server-related
properties into wider use, and help disambiguate them from the
standard layer metadata properties
If the project crs() is a compound CRS, then the CRS returned
by QgsProject::verticalCrs() be the vertical component of
QgsProject::crs(). Otherwise it will be the value explicitly
set by a call to setVerticalCrs().
The vertical crs is a persistent property of a project, which
is saved/restored to xml.
Instead of just setting the whole widget as disabled, implement proper
read-only state for these widgets. This fixes an annoying UI issue where
the list / key value widgets can't be scrolled when opening read-only
attribute forms, preventing users from viewing all the entries in
the widget.
