Michael Voříšek

> sub-scoping model This is quite legit argument - only in this case it can be changed to system But `=` equal condition definitely does not imply that. I think,...

we can not - scope can be further modified

The only usecase I see is strictly "helpful/simplified logic for conditions creation in model setup" so I stay firm behind my "two options" - drop completely or allow to define...

> How to define the difference between addCondition when it is definite and addEqualToSystemCondition (or however we call it)? as addEqualToSystemCondition will call addCondition, it behaves 1:1, only with addEqualToSystemCondition...

> We can add BC support purely in `Model::addCondition` method. this and the sensetence below are two different things, right? :) `addCondition` should not support this, you have to explictly...

> Model does not work as this needs to be triggered on model change absolutely not - you use `addEqualsToSystemCondition` and it sets immediatelly, very predictable and fully controlled

I understand the idea of this, for modelling, if and only if a condition is definitive (is always valid), default value can be set, but: a) PK/ID should never be...

as mentioned in https://github.com/atk4/data/issues/662#issuecomment-663545433, we need to check if definitive definitely :) the current design seems to work well, but the problem is when a condition is removed, is this...

very simillar feature request: https://github.com/atk4/data/issues/319

Data from a different persistence can be materialized thru php and passed to the selecting/owning Model using "select multiple rows with constants" - https://stackoverflow.com/questions/2201170/how-to-select-multiple-rows-filled-with-constants