Werk 16384 was adapted. The following is the new Werk, a diff is shown at the end of the
message.
[//]: # (werk v2)
# notification rule: allow for non builtin service levels
key | value
---------- | ---
date | 2024-01-17T11:19:06+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
```
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver", "to_level":
"gold"}
}
}
```
New schema
```
{"match_service_levels: {
"state": "enabled",
"value": {"from_level": 10, "to_level": 20}
}
}
```
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# notification rule: allow for non builtin service levels
key | value
---------- | ---
date | 2024-01-17T11:19:06+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
```
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver",
"to_level": "gold"}
}
}
```
New schema
```
{"match_service_levels: {
"state": "enabled",
- "value": {"from_level" 10, "to_level": 20}
+ "value": {"from_level": 10, "to_level": 20}
? +
}
}
```
Show replies by date