Bug report #20573
Regression: outputs of processing models are not assigned the specified styles
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Processing/Modeller | ||
| Affected QGIS version: | 3.4.1 | Regression?: | Yes |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 28393 |
Description
In the processing toolbox, right-click on an algorithm and choose "edit rendering styles for outputs". Assign style(s), and try running the algorithm. The output layer(s) will be assigned the correct styles.
However, repeat this for a processing model and the output layers will not be assigned the correct styles. This worked in previous versions e.g. 2.18.23, but it does not work in either 3.4.1 or 3.2.3 - maybe it has always been a problem in 3.x?
Tested on Windows
Associated revisions
[processing] correctly set output styles for models
fixes #20573
History
#1
Updated by Alister Hood about 6 years ago
- Description updated (diff)
#2
Updated by Giovanni Manghi about 6 years ago
- Priority changed from Normal to High
#3
Updated by Alister Hood almost 6 years ago
There is a workaround - incorporate "set style for raster layer" and "set style for vector layer" in the processing model.
So I'm not sure that "high priority" is really justified in this case. I assume it is being set for all regressions?
#4
Updated by Giovanni Manghi almost 6 years ago
Alister Hood wrote:
I assume it is being set for all regressions?
yes
#5
Updated by Victor Olaya almost 6 years ago
- % Done changed from 0 to 100
- Status changed from Open to Closed
Applied in changeset qgis|eb47288fac06692748c7017f6f125a1fc66e9561.
#6
Updated by Andy Harfoot over 5 years ago
I have just experienced this bug in 3.4.7 (package installer) on Windows 10, so it is possible another regression has occurred. The styles are correctly applied in 3.6.2 on the same system.
#7
Updated by Alister Hood over 5 years ago
I think the fix wasn't made in the 3.4 branch.
#8
Updated by Andy Harfoot over 5 years ago
Alister Hood wrote:
I think the fix wasn't made in the 3.4 branch.
Confirmed - the diffs of the revision aren't applied in the 3.4.7 files. I'm surprised at this, given that the 3.4 branch is the current LTR.
#9
Updated by Andy Harfoot over 5 years ago
Manually patching the files fixes the bug in 3.4.7
#10
Updated by Giovanni Manghi over 5 years ago
Andy Harfoot wrote:
Manually patching the files fixes the bug in 3.4.7
please submit a patch on github.