Title: create_host: creating a host with a custom attribute now returns expected attributes
Class: fix
Compatible: compat
Component: rest-api
Date: 1694670257
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.1.0p34
This werk addresses an issue when creating a host with custom attributes. For
example, when you added a new tag to a tag group and then created a host with
that tag group: tag value, the created host would have this new attribute but
it wouldn't have any other attributes.
So sending this in your request, after creating the new tag 'tag1',
C+:
{
"folder": "~",
"host_name": "api_created_host2",
"attributes": {
"ipaddress": "127.0.0.1",
"tag_agent": "no-agent",
"tag_snmp_ds": "no-snmp",
"tag_networking": "tag1"
}
}
C-:
before this would create a host with the only the tag networking attribute
and ignore all others, like so
C+:
{
...
"attributes" {
"tag_networking": "tag1"
}
C-:
Now, we return all the expected attributes.
Title: notification rules: match_folder value now matches correctly to available folders
Class: fix
Compatible: incomp
Component: rest-api
Date: 1694514118
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.2.0p10
This werk addresses an issue when creating or updating a notification rule
via the REST-API. Previously, it would not correctly match the desired folder
and as a result, you had to set this option to disabled which meant all rules
were created in the main folder only.
Now the match_folder value field should match a folder id, in the form of the
folder path, replacing / for ~
E.g.
/folder1 -> ~folder1
/folder1/folder2 -> ~folder1~folder2
Title: create_host: creating a host with a custom attribute now returns expected attributes
Class: fix
Compatible: compat
Component: rest-api
Date: 1694670257
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.2.0p10
This werk addresses an issue when creating a host with custom attributes. For
example, when you added a new tag to a tag group and then created a host with
that tag group: tag value, the created host would have this new attribute but
it wouldn't have any other attributes.
So sending this in your request, after creating the new tag 'tag1',
C+:
{
"folder": "~",
"host_name": "api_created_host2",
"attributes": {
"ipaddress": "127.0.0.1",
"tag_agent": "no-agent",
"tag_snmp_ds": "no-snmp",
"tag_networking": "tag1"
}
}
C-:
before this would create a host with the only the tag networking attribute
and ignore all others, like so
C+:
{
...
"attributes" {
"tag_networking": "tag1"
}
C-:
Now, we return all the expected attributes.
Werk 14615 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: check_epower: configurable parameter for upper levels and default values
Class: feature
Compatible: compat
Component: checks
Date: 1691425439
Edition: cre
Knowledge: undoc
Level: 1
Version: 2.2.0p10
Introduces configurable upper levels + default values for `check_epower`
------------------------------------<diff>-------------------------------------------
Title: check_epower: configurable parameter for upper levels and default values
Class: feature
Compatible: compat
Component: checks
Date: 1691425439
Edition: cre
Knowledge: undoc
Level: 1
- Version: 2.2.0p8
? ^
+ Version: 2.2.0p10
? ^^
Introduces configurable upper levels + default values for `check_epower`
Title: create_host: creating a host with a custom attribute now returns expected attributes
Class: fix
Compatible: compat
Component: rest-api
Date: 1694670257
Edition: cre
Knowledge: doc
Level: 1
Version: 2.3.0b1
This werk addresses an issue when creating a host with custom attributes. For
example, when you added a new tag to a tag group and then created a host with
that tag group: tag value, the created host would have this new attribute but
it wouldn't have any other attributes.
So sending this in your request, after creating the new tag 'tag1',
C+:
{
"folder": "~",
"host_name": "api_created_host2",
"attributes": {
"ipaddress": "127.0.0.1",
"tag_agent": "no-agent",
"tag_snmp_ds": "no-snmp",
"tag_networking": "tag1"
}
}
C-:
before this would create a host with the only the tag networking attribute
and ignore all others, like so
C+:
{
...
"attributes" {
"tag_networking": "tag1"
}
C-:
Now, we return all the expected attributes.
Title: oracle_instances: Fixed parsing of section with failure and additional information
Class: fix
Compatible: compat
Component: checks
Date: 1694187291
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.0.0p39
Sometimes when an oracle instance has a failure it deliveres some additional information. This information caused the failure of the section parsing.
The section in the agent output looks something like this:
C+:
<<<oracle_instance:sep(124)>>>
+ASM|FAILURE|ERROR: ORA-12541: ...
NAME DATABASE_ROLE OPEN_MODE DB_UNIQUE_NAME FLASHBACK_ON FORCE_LOGGING SWITCHOVER_STATUS
C-:
This has now been fixed and the additional information should not cause any problems.
Title: mssql_backup: Now mssql_backup finds backup even if collation is case sensitive
Class: fix
Compatible: compat
Component: checks
Date: 1694612939
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.1.0p34
Previously, if the collation was case sensitive some of the backup were not found.
This has now been fixed and the backups will be found regardless of case sensitivity.
Title: oracle_instances: Fixed parsing of section with failure and additional information
Class: fix
Compatible: compat
Component: checks
Date: 1694187291
Edition: cre
Knowledge: doc
Level: 1
Version: 2.1.0p34
Sometimes when an oracle instance has a failure it deliveres some additional information. This information caused the failure of the section parsing.
The section in the agent output looks something like this:
C+:
<<<oracle_instance:sep(124)>>>
+ASM|FAILURE|ERROR: ORA-12541: ...
NAME DATABASE_ROLE OPEN_MODE DB_UNIQUE_NAME FLASHBACK_ON FORCE_LOGGING SWITCHOVER_STATUS
C-:
This has now been fixed and the additional information should not cause any problems.
Title: mssql_backup: Now mssql_backup finds backup even if collation is case sensitive
Class: fix
Compatible: compat
Component: checks
Date: 1694612939
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.3.0b1
Previously, if the collation was case sensitive some of the backup were not found.
This has now been fixed and the backups will be found regardless of case sensitivity.