Skip to main content

Hi!

We have for now some places in app where we do want some precision for our fields, usually we use type numeric with different specifications depending on the needs.

The problem that we have is that we don't always want to show all the decimals, we need them for some calculations still.

It is already something to do that and we just didn't find out what? Is weird to display that many decimals if the user doesn't need them but for background calculations are needed. (This example maybe is a bit to much, but for 6,8,10 decimals can be some situations and still are a lot to display)

If not, we don't want to fake with with a field of another type with some format and so, maybe we can have another setting on the domain for this situations where we can specify display decimals. (other cases can be for description fields for example if you want just a preview of description and maybe more uses).

​@Ionut We currently don't support that, except for using different (Expression) fields, but it would indeed be valuable if we did. There's an Idea open on this topic, please make sure to add your vote and use case(s):

 

​@Ionut there are two solutions we use, besides that we all wait for formal field formatting options, the simplest is when you already have a view or don't mind having a view to have base table with high precision numbers, and the view with lower precision for users. 

The other one is to have a calculated field on db level with a different domain (low precision) that just looks at the base field with high precision. 

To be noted: The view field you can make editable for input (low precision), where the calculation fills the high precision field. The calculated field is always read only. 

But as said, looking forward to seeing custom display formats and pre-/suffix options to clarify on unit of measure. 

Ok.

Thanks both for answers, now is clear, until we have it we'll see which option is best.

FYI: I also decided to add the Idea I referred to the list of ‘Ideas to be 10X faster’:

 

Reply


Terms & ConditionsCookie settings