Filter a query by Operation.input-inputs-outcomes

[GohuHQ]

I tried to use Operation.input or Operation.inputs or Operation.outcomes as filters for a query. But it's impossible due to the fact that those are Python properties.
So i used Operation.HistoryInput or Avatar.reason according to my need to do what i needed.

After discussion, the solution seems to use Method fields instead of Python properties.

[gracinet]

I've been thinking a bit more about this. It's true that making these first class fields, leveraging Anyblok function fields would be a good thing.

But there's also more to it in the case of outcomes: currently, outcomes are recorded through the reason field of Avatars. Originally (before the separate concept of Avatar arose) that was meant to indicate which was the Operation responsible for the latest mutation (hence not only creation of an Avatar) Nowadays, I tend to think of Avatars as traces that an Operation occurred, ie, it's a bit more general than location and time. It's mostly the same thing in most cases, but the case of Observation (not yet merged) is enlightening : I felt it was necessary to create a new Avatar, even though there's no change in location, because it would help history tracking.

Therefore I think it would be clearer to rename the reason field as outcome_of and consider it to be essentially read-only (we curentlty mutate it upon changes of dt_until). This would make history tracking clearer and robuster, and outcomes would then just be a regular One2Many field.

In the same vein, followers and follows should probably be made first class fields, too.