Time Condition deletion causes callflow failed due to reindexing

This site is best viewed in a modern browser with JavaScript enabled.

Time Condition deletion causes callflow failed due to reindexing

noppakoon

Since Issabel 4 with asterisk 16.16 announcement, if you delete a time condition (not last id such as id 5), issabel will reindex all time condition ids which are greater than 5 by reducing each one by 1 so the 6th becomes 5, the 7th becomes 6 and so on. Other modules which refers to those reindexed time condition ids will work wrongly because it still use the same time condition ids and now all those ids are not the same ones anymore. More importantly it's very difficult to correct this, especially when your callflow used many time conditions to check the operational working schedules and you might forget them what or why you have created them for.

So I decided not to use this time condition reindexing feature anymore, I comment the reindexing sql command in the /var/www/html/admin/modules/timeconditions/functions.inc.php as below.

// $results = sql("UPDATE timeconditions SET timeconditions_id=timeconditions_id-1 WHERE timeconditions_id>\"$id\"","query");

This will help IssabelPBX not to reindex the time condition ids.

priscillasalmon

Yes @ geometry dash 3d, that behavior in Issabel PBX (since the release with Asterisk 16.16) comes from the reindexing query executed when a time condition is deleted.

By default the module runs:

$results = sql("UPDATE timeconditions SET timeconditions_id=timeconditions_id-1 WHERE timeconditions_id>\"$id\"","query");

This renumbers all higher IDs, which breaks references in other modules that still point to the old IDs.

Your workaround is correct: commenting out that SQL line in:

/var/www/html/admin/modules/timeconditions/functions.inc.php

prevents the automatic reindexing, so existing time condition IDs remain unchanged, avoiding call-flow mismatches in modules that reference them.

Just note that after this change, deleted IDs will remain unused (gaps in numbering), which is generally harmless and safer for systems with complex call flows.