Bug report #20573

Regression: outputs of processing models are not assigned the specified styles

Added by Alister Hood over 1 year ago. Updated about 1 year ago.

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

Revision eb47288f
Added by Victor Olaya over 1 year ago

[processing] correctly set output styles for models

fixes #20573

History

#1 Updated by Alister Hood over 1 year ago

  • Description updated (diff)

#2 Updated by Giovanni Manghi over 1 year ago

  • Priority changed from Normal to High

#3 Updated by Alister Hood over 1 year 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 over 1 year ago

Alister Hood wrote:

I assume it is being set for all regressions?

yes

#5 Updated by Victor Olaya over 1 year ago

  • % Done changed from 0 to 100
  • Status changed from Open to Closed

#6 Updated by Andy Harfoot about 1 year 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 about 1 year ago

I think the fix wasn't made in the 3.4 branch.

#8 Updated by Andy Harfoot about 1 year 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 about 1 year ago

Manually patching the files fixes the bug in 3.4.7

#10 Updated by Giovanni Manghi about 1 year ago

Andy Harfoot wrote:

Manually patching the files fixes the bug in 3.4.7

please submit a patch on github.

Also available in: Atom PDF