A bit related topic is ZBXNEXT-2355

ZBX-10265 also considers duplicated events creation as a bad idea.

(1) [I] Data import

ERROR 1054 (42S22) at line 937: Unknown column 'recovery_msg' in 'field list'

wiper RESOLVED in r60330

sandis.neilands CLOSED.

(2) [D] Escalation cancellation changes.

This update also changes how server processes cancelled (host/item/trigger/action disabled/deleted) escalations. Before server sent message about cancellation to all message recipients listed in the next escallation step. This means that users that have been notified during previous escalation steps will not receive cancellation message. If escalation was sleeping then nobody would receive cancellation message.

Now when escalation is cancelled the message is sent all users that were notified during previous escalation steps (like recovery message).

wiper Merged with (21),
CLOSED

(3) [I] Database patch is ready for testing in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-3101

wiper RESOLVED

sandis.neilands CLOSED.

Matrix of test-cases and database for 3.0.3 for upgrading to 3.2. attached.

• Valgrind: OK.
• LLVM scan-build: OK.
• clang with extra warnings: OK (except for structure initialization warnings).
• Found functional issues resolved (see sub-issues below with [I] tag): OK.
• Brief code review: OK.

(4) [S] execute_recovery_operations() calls add_sentusers_msg() with parameters subject=action->r_shortdata, message=action->r_longdata. A few lines above subject and message are set conditionally but are not used.

wiper RESOLVED in r60425

sandis.neilands CLOSED.

(5) [I] In data.tmpl we must add default recovery operations that replace default recovery message.

wiper RESOLVED in r60426

sandis.neilands CLOSED.

sandis.neilands REOPENED. We must also add default recovery messages to opmessage table.

wiper RESOLVED in r60848

sandis.neilands REOPENED. data.tmpl must be changed as well.

wiper RESOLVED in r60859

sandis.neilands CLOSED.

(6) [I] Should we log custom formulas as they are before modification during the upgrade?

wiper After a short discussion it was decided to be more trouble than it's worth.
CLOSED

(7) [A] frontends/php/include/classes/api/services/CAction.php:1327 validateOperationsIntegrity(): incorrect variable name

$type must be renamed to $recovery

oleg.egorov RESOLVED in r60434

sasha CLOSED

(8) [A] validateOperationsIntegrity(): composite translation strings is not allowed.

For example:

if ($type == ACTION_OPERATION) {
    $action_type = _('operation');
}
else {
    $action_type = _('recovery operation');
}

_('No message recipients for %1$s.', $action_type)

oleg.egorov RESOLVED in r60434

sasha undoing string changes in r60571 and r60572. RESOLVED

oleg.egorov CLOSED

(9) [A] some unsupported fields throws an exception, some are silently ignored

oleg.egorov RESOLVED in r60434

sasha CLOSED

(10) [A] recovery_operations can be added for trigger and internal actions only

oleg.egorov RESOLVED in r60543, r60544

sasha this code can be removed because recovery operations will be validated in {{validateOperationIntegrity()}

REOPENED

oleg.egorov RESOLVED in r60715

iivs CLOSED

(11) [A] validateOperationsIntegrity() validation must be added for operation types depending on eventsource

operations

• T - EVENT_SOURCE_TRIGGERS
• D - EVENT_SOURCE_DISCOVERY
• AR - EVENT_SOURCE_AUTO_REGISTRATION
• I - EVENT_SOURCE_INTERNAL

  	T	D	AR	I
  OPERATION_TYPE_MESSAGE	x	x	x	x
  OPERATION_TYPE_COMMAND	x	x	x
  OPERATION_TYPE_GROUP_ADD		x	x
  OPERATION_TYPE_GROUP_REMOVE		x
  OPERATION_TYPE_TEMPLATE_ADD		x	x
  OPERATION_TYPE_TEMPLATE_REMOVE		x
  OPERATION_TYPE_HOST_ADD		x	x
  OPERATION_TYPE_HOST_REMOVE		x
  OPERATION_TYPE_HOST_ENABLE		x
  OPERATION_TYPE_HOST_DISABLE		x	x
  OPERATION_TYPE_HOST_INVENTORY		x	x

recovery_operations

• T - EVENT_SOURCE_TRIGGERS
• D - EVENT_SOURCE_DISCOVERY
• AR - EVENT_SOURCE_AUTO_REGISTRATION
• I - EVENT_SOURCE_INTERNAL

  	T	D	AR	I
  OPERATION_TYPE_MESSAGE	x	-	-	x
  OPERATION_TYPE_COMMAND	x	-	-	-
  OPERATION_TYPE_RECOVERY_MESSAGE	x	-	-	x

oleg.egorov RESOLVED in r60567

sasha Code was improved in r60573. Please, take a look.

RESOLVED

iivs

• When I create an action with EVENT_SOURCE_AUTO_REGISTRATION or EVENT_SOURCE_DISCOVERY and add a recovery operation, it saves with success. According to this table, it's not quite correct. For example if I choose EVENT_SOURCE_TRIGGERS and try to add for example OPERATION_TYPE_HOST_ADD, I get an error "Incorrect action operation type.". Shouldn't this be done the same way?
• The message should explain more where the problem is. If we add both operations and recovery operations, it's hard to find where the problem is. I propose to change it to something more like this "Incorrect action operation type "%1$s" for event source "%2$s".".

oleg.egorov RESOLVED in r60792

iivs CLOSED

(12) [A] The new condition is not correct

old:

if ((isset($operation['esc_step_from']) || isset($operation['esc_step_to'])) && !isset($operation['esc_step_from'], $operation['esc_step_to'])) {

new:

if ((array_key_exists('esc_step_from', $operation) || array_key_exists('esc_step_to', $operation))
        && (!array_key_exists('esc_step_from', $operation)
            && !array_key_exists('esc_step_to', $operation))) {

oleg.egorov RESOLVED in r60536

sasha CLOSED

(13) [A] this translation string was changed mistakenly?

- _('esc_step_from and esc_step_to must be set together.')
+ _('esc_step_from and esc_step_to must be set together in action operation.')

oleg.egorov Not mistakenly, the main was idea to make error message more understandable. But issue open to discuss.

sasha similar changes

- 'No execution target specified for action operation command "%s".'
+ 'No execution target specified for action operation command "%1$s".'

- 'No authentication type specified for action operation command "%s".'
+ 'No authentication type specified for action operation command "%1$s".'

... and more 6 messages

oleg.egorov "%s" - incorrect syntax

sasha CLOSED

(14) [A] double check for existence of the esc_period

if (array_key_exists('esc_period', $operation)) {
    if (array_key_exists('esc_period', $operation) && $operation['esc_period'] != 0
            && $operation['esc_period'] < SEC_PER_MIN) {
        ...
    }
}

oleg.egorov RESOLVED in r60536

sasha CLOSED

(15) [A] these conditions cannot be replaced in such a way

1. if (!isset($operation['opcommand']['type'])) {
   
   if (!array_key_exists('type', $operation['opcommand'])) {
   

2. if ((!isset($operation['opcommand']['command']) || ...
   
   if ((!array_key_exists('command', $operation['opcommand']) || ...
   

oleg.egorov RESOLVED in r60536

sasha CLOSED

(16) [I] data.tmpl is broken.

ERROR:  insert or update on table "screens" violates foreign key constraint "c_screens_3"
DETAIL:  Key (userid)=(1) is not present in table "users".

wiper Apparently we have to move users table in before screens table (or better to the top of file) in schema.tmpl file. Data is exported in the order the tables are listed in schema.tmpl file and in 3.0 we had foreign keys addded from screens to users table.

Two patches - one with data exported with our export script, the second with data edited manually. Both generates databases with identical mysql dumps, so pick your poison.

wiper RESOLVED in r60478

sandis.neilands CLOSED.

(17) [F] The operation condition will not be available for recovery operations, right?

oleg.egorov Based on specification

Recovery operation form will not contain:
Steps
Step duration
Conditions

Yes, conditions will be not available in recovery operations

sandis.neilands Thanks, CLOSED.

(18) [S] recovery field of DB_ACTION is assigned to integer literals. It would be better to use constants to improve readability.

wiper RESOLVED in r60522

sandis.neilands CLOSED.

(19) [S] execute_recovery_operations() should not handle OPERATION_TYPE_MESSAGE, it is handled by execute_operations().

wiper According to specs (screenshot) recovery operations must handle both - OPERATION_TYPE_MESSAGE (send message to user/group) and OPERATION_TYPE_RECOVERY_MESSAGE (send message to previously notified users)

sandis.neilands My mistake, sorry. CLOSED.

(20) [S] We have two static execute_operations() functions. Would be better to rename one of them.

wiper RESOLVED in r60524

sandis.neilands CLOSED.

(21) [D] Escalation cancellation logic has changed, the documentation must be updated accordingly.

https://www.zabbix.com/documentation/3.2/manual/config/notifications/action/escalations?s[]=cancel

In the future it would be nice to be able to set cancellation operations somehow (ZBXNEXT-3294)

wiper merging with (2) subissue wich basically is about the same thing:

This update also changes how server processes cancelled (host/item/trigger/action disabled/deleted) escalations. Before server sent message about cancellation to all message recipients listed in the next escallation step. This means that users that have been notified during previous escalation steps will not receive cancellation message. If escalation was sleeping then nobody would receive cancellation message.

Now when escalation is cancelled the message is sent all users that were notified during previous escalation steps (like recovery message).

martins-v The new logic mentioned in https://www.zabbix.com/documentation/3.2/manual/config/notifications/action/escalations - "(canncellation) message is sent to all who received the notifications before". RESOLVED

sandis.neilands CLOSED.

(22) [design] [I] [F] When a compiler notices an undefined variable it spits out an error showing the location. The compiler doesn't try to fix erroneous source code for us. If a new compiler doesn't support some feature of the previous one it will point to the error location.

During the upgrade we remove the deprecated conditions (trigger value = OK, etc). This is wrong because:

• it is not transparent;
• the modifications still leave us with broken system that must be fixed manually;
• it causes usability issues:
  • half of the actions could be modified and the list would look differently after upgrade making it more difficult to move the operations to recovery operations of other actions
  • the expressions would look different and the original expressions would be lost;
  • some actions could have been disabled before the upgrade by the user. Distinguishing these from the ones disabled by Zabbix would be impossible.

How difficult would it be to:

• display the deprecated conditions in red in frontend;
• do not allow enabling actions with deprecated conditions;
• do not allow adding the deprecated condition?

sandis.neilands CLOSED for two reasons.
1. We are taking the upgrade approach.
2. This proposal wouldn't handle cases where the semantics of the action have changed however the conditions were not modified. For example - a trigger action with OR evaluation type and without 'Trigger value = OK' and 'Trigger value = PROBLEM' conditions after upgrade would not have recovery operations defined although before upgrade it would have executed operations for both OK and PROBLEM events.

(23) [S] server crashes when executing recovery operations because of incorect database select column indexing.
RESOLVED in r60630

sandis.neilands CLOSED.

(24) [S] according to specification update database patch must convert operations to recovery operations where it is possible (if action is strictly based on success event).

wiper RESOLVED in r60635

sandis.neilands Works as intended if:

• operations doesn't contain escalation steps (with delays, conditions, etc.);
• recovery message not selected.

Otherwise - recovery operations are collapsed and executed without delay, recovery message overrides default message from the original operation.

If this is OK, then this sub-issue can be closed.

wiper Actually it's even worse. We can convert operations only if:

• operations have only one escalation step
• there are no operation based conditions
• action recovery_msg isn't enabled or there are no 'send message' operations

Plus if action has 'send message' operations we must copy subject/message to recovery subject/message. It's getting overly complicated.
REOPENED

wiper RESOLVED in r60796

sandis.neilands CLOSED.

(25) /tests/data/data_test.sql: 66-74
Since recovery_msg no longer exists, I believe it should be removed from there as well.

oleg.egorov RESOLVED in r60666

iivs CLOSED

(26) [F] Removed duplicate unit test entry in r60647. Please review.

oleg.egorov CLOSED

(27) [F] action.create:
action without operations and with only recovery_operations parameter.

Undefined index: operations [hosts.php:186 → CFrontendApiWrapper->create() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->create() → CAction->validateCreate() in include\classes\api\services\CAction.php:2333]
Invalid argument supplied for foreach() [hosts.php:186 → CFrontendApiWrapper->create() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->create() → CAction->validateCreate() in include\classes\api\services\CAction.php:2333]
Undefined index: operations [hosts.php:186 → CFrontendApiWrapper->create() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->create() in include\classes\api\services\CAction.php:546]
Invalid argument supplied for foreach() [hosts.php:186 → CFrontendApiWrapper->create() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->create() in include\classes\api\services\CAction.php:546]
Incorrect parameter for operations.

So there should at least one of them. Either operations or recovery_operations.

oleg.egorov RESOLVED in r60664, r60667

iivs CLOSED

(28) [A] action.create:
1. if 'recovery_operations' => [[]] is empty

Undefined index: operationtype [hosts.php:165 → CFrontendApiWrapper->create() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->create() → CAction->validateCreate() → CAction->validateOperationsIntegrity() in include\classes\api\services\CAction.php:1390]
No recipients for action operation message.

2. if incorrect operation type

'recovery_operations' => [
	['operationtype' => 'asdasd']
]

the error message says "No recipients for action operation message."

3. opcommand accepts anything

 'opcommand' => [
	'type' => 'asdads',
	'command' => 'aaaasdasd',
	'execute_on' => 'aaaa'
]

and results in success. Not sure what I have just created with this. And it seems like it's validated for operations, but not for recovery operations.

4. If operations has fields, but has no operation type, I get an error:

Undefined index: operationtype [hosts.php:234 → CFrontendApiWrapper->create() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->create() → CAction->validateCreate() → CAction->validateOperationsIntegrity() in include\classes\api\services\CAction.php:1392]

action.update:
5. If operations has no operation type but only ID

[
	'actionid' => 41,
	'operations' => [
		[
			'operationid' => 79
		]
	]
]

I get an error:

Undefined index: operationtype [hosts.php:251 ? CFrontendApiWrapper->update() ? CApiWrapper->__call() ? CFrontendApiWrapper->callMethod() ? CApiWrapper->callMethod() ? CFrontendApiWrapper->callClientMethod() ? CLocalApiClient->callMethod() ? call_user_func_array() ? CAction->update() ? CAction->validateUpdate() ? CAction->validateOperationsIntegrity() in include\classes\api\services\CAction.php:1392]
No recipients for action operation message.

6. If recovery operations has no operation type but only ID

[
	'actionid' => 41,
	'recovery_operations' => [
		[
			'operationid' => 78
		]
	]
]

I get an error:

Undefined index: operationtype [hosts.php:253 ? CFrontendApiWrapper->update() ? CApiWrapper->__call() ? CFrontendApiWrapper->callMethod() ? CApiWrapper->callMethod() ? CFrontendApiWrapper->callClientMethod() ? CLocalApiClient->callMethod() ? call_user_func_array() ? CAction->update() ? CAction->validateUpdate() ? CAction->validateOperationsIntegrity() in include\classes\api\services\CAction.php:1392]
No recipients for action operation message.

7. Having no operation ID, but replacing it with another recovery operation with all the fields present, I get a different error:

Cannot perform update statement on table "actions" without values.

I think that operationid is the only mandatory field if user wants to edit recovery operation. Other fields should be optional. Only when type is changed, fields should be revalidated just like in create method.

iivs 7. Seems to be fixed under (33) r60702

oleg.egorov Moved to ZBX-3783 (26)
CLOSED

(29) [A] action.create
If I create both operations and recovery operations, some fields like esc_period, esc_step_from, esc_step_to are being copied from operations to recovery operations. I think those fields should be left alone and use database default values.

oleg.egorov RESOLVED in r60662

iivs If I specify those values, they are still recorded in DB.

REOPENED

oleg.egorov RESOLVED in r60713

iivs CLOSED

(30) The new recovery operation OPERATION_TYPE_RECOVERY_MESSAGE missing from API design docs. It's mentioned in server design, UI screenshots and translation messages (Notify all who received any messages regarding the problem before).

iivs After discussion, the decision was made to add type called "Send recovery message". In details describe what is going to happen "Notify all who received any messages regarding the problem before". The fields for "Send to User groups", "Send to Users" and "Send only to" will not be visible. In addition, when "Default message" is selected, the fields below "Subject" and "Message" should be hidden.

oleg.egorov RESOLVED in r60721

iivs Type OPERATION_TYPE_RECOVERY_MESSAGE should be available only for recovery operations. See (11) for details.

oleg.egorov RESOLVED in r60751

iivs Create new action and change dropdown in recovery operation to "Send recovery message", then change back to "Send message". Observe the error:

Undefined index: mediatypeid [actionconf.php:725 → CView->render() → include() in include\views\configuration.action.edit.php:1343]

oleg.egorov RESOLVED in r60778

iivs For a recovery operation, unselect checkbox "Default message". Change from "Send message" to "Send recovery message". The input field and textarea are still visible. Change back from "Send recovery message" to "Send message", the checkbox is now selected.

oleg.egorov RESOLVED in r60794

iivs CLOSED

(31) [F] When "Remote command" is chosen, the script name field is visible. Also "Authentication method", "User name" and "Port" is visible. There are two fields named "Commands". One is textarea and the other one is input field.

Also I cannot add something in "Target list".

oleg.egorov RESOLVED in r60798

iivs CLOSED

(32) [F] action.update:

[
	'actionid' => 41,
	'recovery_operations' => [],
}

Result:

Cannot perform update statement on table "actions" without values.

oleg.egorov RESOLVED in r60702

iivs I have action with operations, but I cannot remove recovery operations on update.

REOPENED

oleg.egorov RESOLVED in r60717

iivs CLOSED

(33) [F] Cannot create recovery operation without an operation from frontend. The error states: "Field "operations" is mandatory.", but like we discussed perviously it should be possible to add a recovery operation action without operation.

oleg.egorov RESOLVED in r60703

iivs CLOSED

(34) [F] Using GUI, create action with recovery operations and without operations. Edit action and try to add operations. Result:

    Undefined variable: operationid [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() in include\classes\api\services\CAction.php:692]
    Undefined index: operationid [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:972]
    Undefined index: [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:972]
    Undefined index: operationid [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:1025]
    Undefined index: operationid [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:1032]
    Undefined index: operationid [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:1043]
    Undefined index: operationid [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:1217]
    Undefined index: opconditions [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:1222]
    Argument 2 passed to zbx_array_diff() must be of the type array, null given, called in C:\Development\ZBXNEXT-3101\frontends\php\include\classes\api\services\CAction.php on line 1222 and defined [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() → zbx_array_diff() in include\func.inc.php:869]
    array_diff(): Argument #2 is not an array [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() → zbx_array_diff() → array_diff() in include\func.inc.php:873]
    array_diff(): Argument #1 is not an array [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() → zbx_array_diff() → array_diff() in include\func.inc.php:876]
    Invalid argument supplied for foreach() [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() → zbx_array_diff() in include\func.inc.php:897]
    Undefined index: operationid [actionconf.php:206 → CFrontendApiWrapper->update() → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → call_user_func_array() → CAction->update() → CAction->updateOperations() in include\classes\api\services\CAction.php:1230]
    Incorrect field "operationid" name or value in where statement for table "operations".

oleg.egorov RESOLVED in r60706

iivs CLOSED

(35) [D] We must decribe in details what actions will be converted and what actions will be disabled in upgrade notes.

sandis.neilands For trigger actions: the only actions that will not be disabled during the upgrade are:

• AND, AND/OR actions with 'Trigger value = PROBLEM' condition but no 'Trigger value = OK' condition.
• AND, AND/OR actions with 'Trigger value = OK' but no 'Trigger value = PROBLEM' condition (with caveats described in (24).

The rest of the trigger actions (all OR actions, all CUSTOM actions, remaining AND and AND/OR actions) as well as all internal actions will be disabled and will have to be reworked after upgrade. In the best case - the user just have to enable them. In the worst case - completely rework the actions from scratch.

The best approach in this case is to rework the actions before the upgrade.

martins-v I've added a corresponding entry in the Upgrade notes. RESOLVED

sasha CLOSED

(36) [F] Recovery operations are not shown in the 'Actions' page (see no_recovery_operations.png - actions 4 - 7 have only recovery operations). Is this intentional?

iivs Although that information is important to show in list, currently there are no plans to display them, because previously we had recovery message checkbox, that did not affect the list. Also we're still need to discuss how to display them. We could make a new column, or merge them in existing one. So this could be later moved to a new ZBXNEXT.

TL;DR: Yes. Why? Because.

CLOSED

(37) [I] Server crashes during upgrade. In DBpatch_3010023() the last argument for zbx_db_insert_prepare() should be NULL instead of 0. RESOLVED in r60768.

wiper CLOSED

(38) [F] Recovery operation -> Remote command -> Global script not working. Cannot add script from popup:

TypeError: frmStorage is null

oleg.egorov RESOLVED in r60797

iivs CLOSED

(39) [A] Performing action.create/action.update mediatypeid should not be recorded in DB in case of recovery message.

oleg.egorov RESOLVED in r60790

iivs CLOSED

(40) [S] Having an action with recovery operation "Send message" and then followed by another recovery operation "Send recovery message", recovery messages aren't sent to the users/groups specified in the "Send message" operation

wiper RESOLVED in r60780

sandis.neilands CLOSED.

(41) [F] Translation string changes?

oleg.egorov

Strings added:

• Incorrect action operation type "%1$s" for event source "%2$s".
• Notify all who received any messages regarding the problem before
• Recovery operations
• Send recovery message

Strings deleted:

• Action operations
• Incorrect action condition trigger value.
• Incorrect action operation type.
• Item in "normal" state
• Low-level discovery rule in "normal" state
• Recovery message
• Recovery subject
• Trigger in "normal" state
• Trigger value

iivs CLOSED

(42) [F] Item in “normal” state, Low-level discovery rule in “normal” state and Trigger in “normal” state event type conditions are not removed from internal action configuration page.

From specification:

conditions Trigger value = PROBLEM, Trigger value = OK, Event type: Item in “normal” state, Low-level discovery rule in “normal” state and Trigger in “normal” state must be removed and the action formula updated where necessary.

oleg.egorov RESOLVED in r60789

iivs CLOSED

(43) [AF] Code refactoring in r60782, please review.

oleg.egorov REVIEWED! Thank you and please review my changes is 60804

iivs Thanks!
CLOSED

Attached summary and configuration backup (MySQL) for trigger action upgrade testing.

(44) [I] After upgrade for AND and OR actions with all conditions removed the type was not changed to ANDOR.

From specification:

If the updated formula is empty, then action evaluation type must be changed to AND/OR

wiper RESOLVD in r60820

sandis.neilands CLOSED.

(45) [I] Shouldn't we also log which conditions were removed from which actions?

wiper Also added logging when action evaltype is reset to And/or
RESOLVD in r60820

sandis.neilands CLOSED.

(46) [A] Although there are no steps for recovery operations, the option "selectRecoveryOperations" returns extra field "esc_step_to".

RESOLVED in r60795

oleg.egorov CLOSED

(47) [I] Discovery and auto-registration actions are disabled during upgrade.

wiper RESOLVED in r60796

sandis.neilands CLOSED.

(48) [I] After upgrade "OK" internal event actions of different event types (item, LLD, trigger) cannot be distinguished any more.

Example. Three actions are configured.

• Action #1 condition: item in 'normal' state.
• Action #2 condition: LLD rule in 'normal' state.
• Action #3 condition: trigger in 'normal' state.

During upgrade (as per specification):
1. the operations are moved to recovery operations;
2. the "OK" conditions are removed. As a result we have 3 actions that accept any event type.

wiper Yes, we should convert only trigger based actions.
RESOLVED in r60820

sandis.neilands CLOSED.

Frontend TESTED.

Server and DB upgrade TESTED.

Released in:

• pre-3.1.0 r60878

(49) [F] Remote command operation authorization inputs always shows

oleg.egorov RESOLVED in r61017

iivs CLOSED

FIXED in pre-3.1.0 r61059

(50) [F]
1. Go to Configuration->Actions (Triggers)
2. Add new action
3. Add operation “Send message to user”
4. See this warning message

Undefined index: opmessage_grp [actionconf.php:735 → CView->render() → include() → getActionOperationDescriptions() in include\actions.inc.php:588]

gunarspujats RESOLVED in r62016

iivs CLOSED

(51) [D] Updated documentation sections:

• What's new
• Upgrade notes
• Actions
• Conditions (Trigger value and internal event 'ok' conditions removed)
• Operations
• Recovery operations (new section)
• Receiving notifications on unsupported items
• Escalations (screenshots of examples)

The upgrade note entry improved according to suggestions by sandis.neilands and wiper.

RESOLVED

sasha Great job! Thank you. CLOSED

(52) [S] {EVENT.ID} is not properly resolved in recovery operations.

Recovery operation type:

• Notify all who received any messages regarding the problem before
  • {EVENT.ID} resolved into PROBLEM event id it is correct
• Send message to user groups: Zabbix administrators via all media
  • {EVENT.ID} resolved into OK event id it is not correct

Other {EVENT.*} macros also must be checked.

wiper RESOLVED in r61333

sasha CLOSED

(53) [S] Only one recovery notification with same subject/message should be sent by Zabbix server

wiper RESOLVED in r61455. Note that until ZBX-11059 is fixed server still can be configured to send duplicated notifications:

1. add 'send message' operation with 'send only to All' media type
2. add 'send recovery message' operation

However if a specific media is choosed for 'send message' operation, then only a single message is sent.

sasha CLOSED

(54) [D] API documentation updated:

• https://www.zabbix.com/documentation/3.2/manual/api/reference/action/object
• https://www.zabbix.com/documentation/3.2/manual/api/reference/action/create
• https://www.zabbix.com/documentation/3.2/manual/api/reference/action/get
• https://www.zabbix.com/documentation/3.2/manual/api/reference/action/update
• https://www.zabbix.com/documentation/3.2/manual/api/changes_3.0_-_3.2

sasha

1. operations.recovery and recovery_operations.recovery must be removed from documentation. action.get shouldn't return such flags. These flags shouldn't be accessible for action.create and action.update methods
2. > Action object
   • recovery operation object must be described separately
3. action.create
   • recovery flag must be removed from example
   • operations and recovery_operations are not required. One of these options is required.
4. action.get
   • example with recovery operation is needed
5. Parameters in action.create and action.update methods have a different order and formatting
6. Changes from 3.0 to 3.2
   • mentions about recovery flag must be removed

REOPENED

iivs RESOLVED

sasha

1. > Action object#Action operation: Send recovery message (11) operation type is applicable only for recovery operations (must be removed from this table)
2. > Action object#Action recovery operation: opconditions and evaltype are applicable for normal operations only (must be removed from this table)

REOPENED

iivs You're right. RESOLVED

sasha Thanks! CLOSED

Released in:

• 3.2.0alpha2 r61618

Undefined index (50) Fixed in pre-3.2.0beta3 r62168

(56) [F] Error in Internet Explorer browser (versions 9, 10, 11), when create new action operation
1. go to Configuration->Actions (Triggers)
2. add new action
3. press "New" operations (or recovery operation)
Result: all content from action, operation and recovery operation tabs displayed on one page
Errors in console:

SCRIPT1028: Expected identifier, string or number
File: actionconf.php, Line: 449, Column: 4
SCRIPT5009: 'addPopupValues' is undefined
File: actionconf.php, Line: 673, Column: 1

vitalijs.cemeris RESOLVED in svn://svn.zabbix.com/branches/dev/ZBXNEXT-3101 r62380
Issue was caused by using computed names in object property definitions which is introduced in ECMAScript 2015. And IE11 does not support this future.

iivs CLOSED

(57) [I] cannot upgrade IBM DB2 database

  5395:20160907:175426.958 completed 36% of database upgrade
  5395:20160907:175427.013 Action "Report problems to Zabbix administrators" condition "Trigger value = PROBLEM" will be removed during database upgrade: this type of condition is not supported anymore
  5395:20160907:175427.022 [Z3005] query failed: [-119] 42803 [IBM][CLI Driver][DB2/LINUXX8664] SQL0119N  An expression starting with "EVALTYPE" specified in a SELECT clause, HAVING clause, or ORDER BY clause is not specified in the GROUP BY clause or it is in a SELECT clause, HAVING clause, or ORDER BY clause with a column function and no GROUP BY clause is specified.  SQLSTATE=42803 [select a.actionid,a.name,a.evaltype,count(c.conditionid) from actions a left join conditions c on a.actionid=c.actionid group by a.actionid]
  5395:20160907:175427.023 database upgrade failed

 17503:20160907:200425.087 completed 33% of database upgrade
 17503:20160907:200425.137 [Z3005] query failed: [-119] 42803 [IBM][CLI Driver][DB2/LINUXX8664] SQL0119N  An expression starting with "ESC_STEP_TO" specified in a SELECT clause, HAVING clause, or ORDER BY clause is not specified in the GROUP BY clause or it is in a SELECT clause, HAVING clause, or ORDER BY clause with a column function and no GROUP BY clause is specified.  SQLSTATE=42803 [select o.operationtype,o.esc_step_from,o.esc_step_to,count(oc.opconditionid) from operations o left join opconditions oc on oc.operationid=o.operationid where o.actionid=3 group by o.operationid]
 17503:20160907:200425.137 Action "Report problems to Zabbix administrators" operations will be converted to recovery operations during database upgrade.
 17503:20160907:200425.137 Action "Report problems to Zabbix administrators PROBLEM" will be disabled during database upgrade: conditions might have matched success event which is not supported anymore.
 17503:20160907:200425.137 Action "Report not supported items" will be disabled during database upgrade: conditions might have matched success event which is not supported anymore.
 17503:20160907:200425.138 Action "Report not supported low level discovery rules" will be disabled during database upgrade: conditions might have matched success event which is not supported anymore.
 17503:20160907:200425.138 Action "Report unknown triggers" will be disabled during database upgrade: conditions might have matched success event which is not supported anymore.
 17503:20160907:200425.139 database upgrade failed

sasha RESOLVED directly in trunk in pre-3.2.0rc1 r62363

sandis.neilands, please have a look at these changes.

sandis.neilands CLOSED.

Action operations edit form view (56)
Fixed in pre-3.2.0rc1 r62392

Improved ChangeLog entry for sub-issue (56) in r62393