I think a wildcard would work better, especially in cases like mine. The Items I want to aggregate are external checks. For each Host, one of the parameters sent to the external script changes. But otherwise, all of the keys in the Items are exactly the same.
On each Host in the Host Group "Clydesdale Hall" is an external check (which was, in turn, created by a Discovery rule). The key for the external check looks like this:
Only the IP address of the access point changes. I'd like to be able to create an aggregate Item with a key like one of these:
Based on the Discovery rule:
In my case, an exception for aggregating external checks that would match against only the script name and ignore the parameters would work as well (perhaps as a checkbox in the configuration of the aggregate item?), but that may be too specific a case to write code for. A true wildcard would be far more flexible, if it's feasible.
If wildcards create the potential for users to accidentally aggregate thousands of Items and destroy their systems, the Web UI could run a check when the user clicks Save. If the number of aggregated Items is more than 1000, a warning could pop up that asks the user to confirm the change. "The key you've entered will aggregate 13947810 Items. Are you sure you want to proceed? [ OK ] [ Back to Item Config ]"