"Control feature rendering order" is unchecked and cleared when the layer style mode is switched

[qgib]

Author Name: Harrissou Santanna (@DelazJ)
Original Redmine Issue: 14347
Affected QGIS version: master
Redmine category:symbology
Assignee: Sebastian Dietrich

---

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.

[qgib]

Author Name: Sebastian Dietrich (Sebastian Dietrich)

---

See "PR 2831":#2831 for a solution.

---

• status_id was changed from Open to In Progress
• assigned_to_id was configured as Sebastian Dietrich
• done_ratio was changed from 0 to 100
• pull_request_patch_supplied was changed from 0 to 1

[qgib]

Author Name: Sebastian Dietrich (Sebastian Dietrich)

---

Note that it is Control feature rendering order, not Control layer rendering order. I changed that in the subject and description.

---

• subject was 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

[qgib]

Author Name: Sebastian Dietrich (Sebastian Dietrich)

---

Set to 50% because of side effects detected in the proposed solution.

---

• done_ratio was changed from 100 to 50

[qgib]

Author Name: Andreas Neumann (@andreasneumann)

---

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.

---

• priority_id was changed from Severe/Regression to High

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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?

---

• priority_id was changed from High to Normal

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• regression was configured as 0
• easy_fix was configured as 0

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

End of life notice: QGIS 2.18 LTR

Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/

---

• resolution was changed from to end of life
• status_id was changed from In Progress to Closed