If we end up with notable changes for end-user they should be documented here:

http://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew203

Also current situation (regression) is documented here:

http://www.zabbix.com/documentation/2.0/manual/appendix/macros/supported_by_location#macros_supported_by_location

The reason this happened is because since 2.0.3 for HOST.* macros in an item keys we get information from the interface attached to the item. So the macros are not resolved anymore for items that do not have interfaces attached.

Sasha proposed to make the changes to Frontend to optionally select an interface for active agent items. That would not require any changes on the server side. So it's not clear which Component/s are related to this issue yet.

<zalex> Only for agent (active) items ?
How about calculated, aggregate, odbc items?

<dimir> We could not see a use case for others. Database monitor could be also the case, for additional parameters for example, as you point out below.

For calculated and odbc items it has no sense because KEY field is useless (only for identification)
All calculation (dbquery) is done in Additional parameters/Formula field.

Bests,
Grzegorz

But what if I want to use some HOST.* macro in a SQL query of an ODBC item ?

It never work (before). Only user macro works.
No system macro works in Additional parameters but it will be good if it will be .

Now you have to use user macro and retype ex. {$HOST.IP} = 10.1.1.1 for host if you want use macro in Additional parameters.

Probably it should be fixed by allowing optional interface linkage for items.

Being able to use system macros in ODBC additional parameters would be nice. I have a similar configuration and have to manually edit the ODBC item for each host. It would be great if I could stick this in a template.

Is there a eta for this fix?

Is there a chance to include this fix in 2.0.3?

definitely not, as there is no fix yet, and 2.0.3 is about to be released

Any chance to get this thing fixed soon?

I did the migration from 1.8.x to 2.0.5 today and am affected, too.

ZBXNEXT-2896 wants the same for external checks.

Should be moved to ZBXNEXT project, I think.