[ZBX-10447] Concatenation of macros in calculated item expression Created: 2016 Feb 24 Updated: 2019 Dec 10 |
|
Status: | Open |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Frontend (F), Server (S) |
Affects Version/s: | 3.0.0 |
Fix Version/s: | None |
Type: | Incident report | Priority: | Trivial |
Reporter: | Glebs Ivanovskis (Inactive) | Assignee: | Zabbix Development Team |
Resolution: | Unresolved | Votes: | 0 |
Labels: | calculateditems, expressions, frontend, macros, server | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
Provided {$MACRO} stores numeric value (positive integer to be precise) one can use the following construction in calculated item expression: {$MACRO}{$MACRO} Implicit concatenation is the last thing to expect from numeric values in mathematical expression. Implied multiplication would be more appropriate since it is a commonly accepted mathematical notation. In trigger expressions such constructions are not allowed, this can be a way to go too. Depending on the desired behaviour this issue should be treated as frontend or server bug. |
Comments |
Comment by richlv [ 2016 Feb 24 ] |
on the other hand, people have asked for an ability to have arbitrary concatenation in calculated items even to form item keys like last({$SMTH}_time) - maybe going towards max flexibility is better |
Comment by Glebs Ivanovskis (Inactive) [ 2016 Feb 24 ] |
Being a C kind of person I gravitate towards many type-specific functions and explicit type conversion. |
Comment by richlv [ 2016 Feb 24 ] |
being strict wouldn't be that bad, but it would require implementing even more complexity, like maybe functions to concatenate, convert to strings etc in calculated items. it might be a bit too much for users, and it might be hard to develop, too |