Problem/Motivation
The conclusion reached by #2392845: Add a trait to standardize handling of computed item lists is that a computed field needs a couple of things:
1) a custom field item list class which contains a method responsible for computing the values
2) implement all the "entry points" which can be used to access the field value and call that method
In that issue, a trait has been added to help developers with the second point mentioned above, so they only need to take care of the method which computes the field value(s) "on demand".
This all works out well for fields defined in code, usually base fields, because they can specify a custom field items list to be used instead of the default one. However, fields defined in the UI have no way of doing the same thing, so they can't be marked as computed at the moment.
Proposed resolution
Figure out a solution for how to declare a field added in the UI as computed.
Remaining tasks
TBD.
User interface changes
Maybe a new setting / checkbox in the UI?
API changes
TBD.
Data model changes
TBD.