accepts the prompt to save the changes BUT then cancels the file dialog
asking for the destination file name, don't treat this as though the
user has opted to discard the model
Specifically, this fixes two issues
1. If a user edits a dark green output block in a model and changes the
name of the output, that new name was always discarded and the only
way to change it was by editing the algorithm it was attached to
2. If an output was renamed through the algorithm properties dialog,
then any properties previously associated with that output (like
comments, coloring, placement, default value, mandatory flag)
would get reset back to their default settings
was a complete match for the old file name, then update the model
name for the saved as model to also match the NEW file name
E.g.
Scenario 1
- user has a model stored as "Save features.model3", named "Save
features"
- user 'saves as' this model as "Delete features.model3"
- the model name is automatically updated to match the new file
name, i.e. "Delete features"
Scenario 2
- user has a model stored as "Save features.model3", named "Process
incoming features from API"
- user 'saves as' this model as "Save features v2.model3"
- the model name is NOT changed, and is left at the original
"Process incoming features from API" name
- When saving a model to a file, don't require that the model already
has a name entered. Instead, if no model name has been entered then
set the model name automatically to match the selected save filename.
E.g. if the user saves the model as "Process incoming features.model3",
then the model name will be set to "Process incoming features".
- When first saving a model, IF the user HAS already entered a model
name then make the default file name suggested by the dialog match
this model name
when configuring a new algorithm
While the previous behaviour of defaulting to a static value makes
sense for things like numeric parameters, this is a very rare use
case for map layer parameters. For better new user experience we can
default instead to showing model inputs for these parameter types.
these are always gracefully caught
Avoids some unwanted "unhandled exception" message boxes which
can pop up while moving the mouse around outside of the valid bounds
of the current map projection
We can't safely handle a distance within query when transforming, as
we cannot transform the static within tolerance distance from one
CRS to a static distance in a different CRS
The method superceeds filterRectToSourceCrs, deprecating it for
shortage of functionality now that we support multiple spatial
filters.
This commit makes use of the new method from
QgsVectorLayerFeatureIterator::QgsVectorLayerFeatureIterator
so to not drop the WithinDistance spatial filter from the
user Request.
References #45352
