Is that custom filed on WORKORDER table?

I assume your attribute is non-persistent in database configuration. Attributes like description are stored in the database on the table. This enables them to be used for sorting, filtering, etc. When the user creates a filter we take that and run it directly against the database so it needs to be persistent.

Non-persistent attributes are used typically for dynamic fields that typically pull data from a separate table (like LONGDESCRIPTION) or are calculated fields. Your custom attribute seems to indicate whether an attachment exists, so it makes sense that when it was set up it was likely setup as non-persistent.

There is another limitation on sorting where something could be persistent but not eligible for sorting. That is when the attribute goes through a relationship like WORKORDER->ASSET using ASSET.SERIALNUM for example. Because of how our queries are built, we can build filters on related attributes that are persistent but we cannot enable sorting on those attributes.

In the new UI framework, there are some architecture differences which would enable device side filtering, sorting, etc. so some of the same limitations won't necessarily apply if we have all the data locally. 

In database configuration the attribute is Persistent, I managed to add a filter option for attachment filed, but the result is not according to the filter.

I assume your attribute is non-persistent in database configuration. Attributes like description are stored in the database on the table. This enables them to be used for sorting, filtering, etc. When the user creates a filter we take that and run it directly against the database so it needs to be persistent.

Non-persistent attributes are used typically for dynamic fields that typically pull data from a separate table (like LONGDESCRIPTION) or are calculated fields. Your custom attribute seems to indicate whether an attachment exists, so it makes sense that when it was set up it was likely setup as non-persistent.

There is another limitation on sorting where something could be persistent but not eligible for sorting. That is when the attribute goes through a relationship like WORKORDER->ASSET using ASSET.SERIALNUM for example. Because of how our queries are built, we can build filters on related attributes that are persistent but we cannot enable sorting on those attributes.

In the new UI framework, there are some architecture differences which would enable device side filtering, sorting, etc. so some of the same limitations won't necessarily apply if we have all the data locally. 

In database configuration the attribute is Persistent, I managed to add a filter option for attachment filed, but the result is not according to the filter.

I assume your attribute is non-persistent in database configuration. Attributes like description are stored in the database on the table. This enables them to be used for sorting, filtering, etc. When the user creates a filter we take that and run it directly against the database so it needs to be persistent.

Non-persistent attributes are used typically for dynamic fields that typically pull data from a separate table (like LONGDESCRIPTION) or are calculated fields. Your custom attribute seems to indicate whether an attachment exists, so it makes sense that when it was set up it was likely setup as non-persistent.

There is another limitation on sorting where something could be persistent but not eligible for sorting. That is when the attribute goes through a relationship like WORKORDER->ASSET using ASSET.SERIALNUM for example. Because of how our queries are built, we can build filters on related attributes that are persistent but we cannot enable sorting on those attributes.

In the new UI framework, there are some architecture differences which would enable device side filtering, sorting, etc. so some of the same limitations won't necessarily apply if we have all the data locally.