Nice suggestions. I agree with the idea of a "calculated" field, but not for the same application. I would have more in mind the possibility of entering values using different units. Say, a pressure measurement. The user could fill in a field named "Pressure" in Pascal, bar, mbar, or mmHg (Torr) and select the unit used. This would go to a "rawValue" field that would be displayed. The actual "value" field would be hidden and contain the calculated standardised value (in Pascal in this case). When a search is done for a pressure value or range, then it could be found regardless of unit used during the search. Ideally all measurements would be in S.I., but everyday research is not like this. Hope this makes sense. It's not a priority, IMO, but would be nice. Unless others can come up with more urgent reasons.

One way users could implement this with the above proposal would be

{
    "extra_fields": [
       {
           "name": "pressure_input",
           "label": "Pressure",
           "type": "number",
       },
       {
           "name": "pressure_unit",
           "label": "Unit of pressure measurement",
           "type": "select",
           "value": "Pascal",
           "options": ["Pascal", "bar", "mmHg"]
       },
       {
           "name": "pressure_value",
           "type": "calculated",
           "show_only_if": "false",
           "formula": "ifelse(eq({pressure_unit}, 'Pascal'), {pressure_input},ifelse(eq({pressure_unit}, 'bar'), {pressure_input} * 100000, {pressure_input} * 133.322))"
       }
   ]
}

It might be nice to provide lots of helper functions already for example for unit conversions,
but you can always start small :-)

Hi Nicolas, @JuliaSprenger, @SylvainTakerkart
I'm coming back to this idea to know if there was anything new or if you had thought about it in terms of feasibility? It would indeed be very useful for many functions, for example to make a field appear when a certain value has been filled in, these are things we use a lot on our side!

I haven't looked into it precisely yet, but I agree it would be an interesting feature.

@NicolasCARPi
Among other benefits, it can help to create user-defined custom id's, as suggested in other issues (i.e. #3724, which you marked as a high priority)

I used similar functionality in Salesforce to create (really) complex id's and was happy with it

I would find such functionality very useful as well. In my case, it would be for acquisition settings on imaging instruments.
For example, on the SEM, different settings make sense depending on the detector used (conditional fields).
Also, resolution on a microscope depends on properties of objectives and light source, so it would be great to have a field that calculates automatically to show the user which optical resolution is achieved with the current settings (calculated fields). Similar idea on our CT where the focal spot size is proportional to the energy, which is calculated from acceleration voltage and current. Only the latter two are user inputs, but it would be good for the user to get the former two shown.

I would be very interested having calculated fields and values. the extra step of manually calculating fields is very error prone since it moves the responsibility from the software to the user.

as a work around this could be solved by using worker scripts which run on a regular basis and fill out all "calculated" fields, but this adds a whole new layer of possible problems.

is this feature something that you plan on implementing, or is it more on the "could be" list?

seems very far on the todolist, I'm currently focusing on other matters that I belive are more important to implement. But the whole idea is good.