Bug report #14347
"Control feature rendering order" is unchecked and cleared when the layer style mode is switched
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | Sebastian Dietrich | ||
Category: | Symbology | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | Yes | Resolution: | end of life |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 22332 |
Description
In vector Layer's Properties --> style, set a single symbol rendering
Then check the "Control feature rendering order" and set a sorting expression and apply also an effect
Switch to, let's say, categorized rendering
The "draw effects" is still active while the rendering order expression has been cleared.
Testing shows that it's kept only if the style has been applied before the switch (what's not required for "draw effects") - and even in that case the behaviour is not consistent.
Given that features ordering may have nothing to do with the features classification, and to be consistent with the other options in the Layer rendering frame, the expression set in the "Control feature rendering order" should not be cleared.
Set it as blocker, given that it's a new feature.
History
#1 Updated by Sebastian Dietrich over 8 years ago
- Status changed from Open to In Progress
- Assignee set to Sebastian Dietrich
- % Done changed from 0 to 100
- Pull Request or Patch supplied changed from No to Yes
See PR 2831 for a solution.
#2 Updated by Sebastian Dietrich over 8 years ago
- Subject changed from "Control Layer rendering order" is unchecked and cleared when the layer style mode is switched to "Control feature rendering order" is unchecked and cleared when the layer style mode is switched
Note that it is Control feature rendering order, not Control layer rendering order. I changed that in the subject and description.
#3 Updated by Sebastian Dietrich over 8 years ago
- % Done changed from 100 to 50
Set to 50% because of side effects detected in the proposed solution.
#4 Updated by Andreas Neumann over 8 years ago
- Priority changed from Severe/Regression to High
I am setting this to priority "high" due to the following reasons:
- it doesn't crash QGIS
- there is no data corruption
- it doesn't display false information
- it isn't a regression, since it did not work before and then suddenly failed.
Category "Severe/Regression" should really be reserved to the above cases.
I agree though that it is annoying and hopefully can be fixed.
#5 Updated by Giovanni Manghi almost 8 years ago
- Priority changed from High to Normal
Andreas Neumann wrote:
I am setting this to priority "high" due to the following reasons:
- it doesn't crash QGIS
- there is no data corruption
- it doesn't display false information
- it isn't a regression, since it did not work before and then suddenly failed.Category "Severe/Regression" should really be reserved to the above cases.
I agree though that it is annoying and hopefully can be fixed.
if there is no crash and no data corruption is also not high.
I'm trying to clean a bit the bug queue, leaving as high the tickets really causing that problems. Later we can eventually raise again the priority of this issue.
By the way... why the patch was not committed?
#6 Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#7 Updated by Giovanni Manghi over 5 years ago
- Resolution set to end of life
- Status changed from In Progress to Closed
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/