Forum Discussion
Hello Tom,
For this you can may be rethink the approach.
On similar scenario, I'm using a relationship instead of multi value list (in general, I systematically avoid list and multi value list on my projects)
from there two possibilities:
1/User works in relationship, but want the list of value visible on the main Form and in the Search Grid of the Item Type
-> implement proxy property (Read Only True, data type string or Text) on Item Type with OnAfterAdd and onAfterUpdate on relationship server event to concatenate values in comma separated value and store in on the proxy property.
2/User doesn't want to work on a relationship:
Nearly same approach, except relationship is not visible to end user, and on the Form, you can place a search button on the side of the proxy property that open a search grid (where all operator are usable as OOTB), User can search and select values then click on OK, server event will add related Item and also make concatenation and store value on proxy property.
One advantage is that by using relationship, you can create a permission and grant add and updated access to a group of user, meaning the list of value can be maintained by customer without further development.
Combine with a boolean property "Active" and server event onBeforeGet this allow customer to deactivate a property (active False) making it not available anymore for a user to use in UI, while keeping value existing in the DB for history purpose (not like list).
Regards
Michael
I am confused by this discussion. :). Isn´t it possible to use wildcard in multi-value lists? At least in AML?
It´s definitely possible to overwrite the behavior of multi value lists to support search parameters like "like" instead of "eq".
But I agree that super long multi-value lists are often better replaced with something more practical - especially inside of relationships they become hard to use.