Tested with both trapper and internal items.

Curiously enough, sending 10000 as a value does translate to 1. From that moment on, translation seems to be working correctly.

See screenshot-1

Could it be that you had a "Decimal" item initially, then switched to "Boolean" and started sending values, but the server's configuration cache still used the old "Decimal" setting for some time?

It was a newly created item which was set to boolean from the start.

I could not reproduce it with trapper items (where the value is obtained externally), but internal items (where the value is obtained from inside the server) do not seem to take "Boolean" setting into account indeed.

Hmm, wait. For the trapper you might be right, issue might be due to config cache there.
The internal item is however definitely set to boolean from the start.

See new screenshot-2 and screenshot-3.

@asaveljevs: Thanks for confirming!

As Raymond already mentioned in ZBXNEXT-3563, there is no possibility to select boolean for calculated and aggregate items. The fact that there is a possibility to select boolean for internal items is probably a frontend bug, so we could theoretically limit it on the frontend side. In other words, the choice of boolean/octal/decimal/hexadecimal is currently meant for values obtained from the outside using strings, rather than in-memory.

However, there are other item types like simple checks where the value can be obtained both internally (e.g., ICMP pings) and externally (VMware items?), so the choice of whether to limit the data type cannot be made based on item type alone. Therefore, this issue looks more like a feature request, so it is proposed to close this as a duplicate of ZBXNEXT-3563. In any case, it should probably be done after ZBXNEXT-1443 and ZBXNEXT-3508, because a lot of related code is likely to change.

If this is considered a frontend bug, can this be resolved under this ZBX or do we need to add a new one referencing this one?

We decided not to fix the frontend right now, because the problem is minor and would not solve the problem fully anyway (e.g., simple checks).

Raymond, would you like to keep this issue open or we can close it as a duplicate of ZBXNEXT-3563?

Seems it was fixed in version 3.4.1 with ZBXNEXT-3006. Now all values, regardless of their source, go through the preprocessing, where the preprocessor step "Boolean to decimal" is applied to them.