breaks SOLID

It doesn't. In fact, if it worked as you expected it would break SOLID

it's definitely a serious design flaw

Sorry to be brutal: No, it's not a flaw, you just didn't understand the design of model/views.
To help you get a better idea of what is going on, try use the same model with 2 different treeviews. In only one of the view call setRootIndex, and then trigger the filtering.

@IMAN4K said in change QSortFilterProxyModel behaviour for multiple column filtering:

Answer from stackfverflow : http://stackoverflow.com/questions/39488901/change-qsortfilterproxymodel-behaviour-for-multiple-column-filtering

This answer is the typical example that lead people to say

subclassing QSortFilterProxyModel, which would likely have a very limited reusability

It's bad. the proxy model implementation should not depend on the structure of the underlying data in sourceModel

Adapted from the documentation example: model->setFilter("should_alarm=1");

You could stack two QSortFilterProxyModels on top of the each other, one filtering on the first column/value, and the other on the second column/value.

Alternatively, you could subclass QSortFilterProxyModel to override filterAcceptsRow() and compare two columns against two filter values (the first is the existing column and value, and a second you add)