* this fix addresses voip_peer_preferences default values
restoration in 15797 and it from now on only restores missing
default values for preferences that do not have peer_pref
with non default value NULL, so that scenarios where a
preference does not exists in voip_peer_preference because
it was manually selected by the customer with the value NULL
so it does not exists in voip_peer_preferences for that reason.
Change-Id: I83ee3294cab896679575187066a3960818dc2f77
(cherry picked from commit 5b840a69e7)
(cherry picked from commit 087235c564)
By default, Prosody automatically handles table management.
As a result, executing the down script will fail because the index
has already been created by Prosody.
Adding IF NOT EXISTS prevents errors when the index already exists.
Change-Id: Ie9289ec5381fd1082047e5c9a762e7a31cf1c55c
(cherry picked from commit f863fe359d)
(cherry picked from commit dd4f81d870)
In some cases, the prosody.prosody table contains duplicated entries.
This causes the 15841.up migration script to fail when creating the
new index.
To prevent this, add a step before dropping/creating the index to
remove all duplicate rows from the table.
Change-Id: I912dd8484231689d5b1f3dc5087bb69a96c496eb
(cherry picked from commit 1bf0fbf03a)
(cherry picked from commit de7eb09ed5)
* site_id is not checked for non db nodes, when revisions are applied,
as site_id there is always null and on db nodes when something is
applied, it becomes not null.
(cherry picked from commit 8cd03ea4a4)
(cherry picked from commit 3b02189dea)
Change-Id: I2b9521db44bf8e3b519f3542046fd87027736c8c
The upscript 15418.up was created in 2018 and recently it was adapted
for debian/trixie. In turn, this will cause warnings in ngcp-status as
ngcp-mysql-compare-dbs script shows inconsistencies between the json
file and the db itself.
Original change:
719fd2750b
Adaptations:
57b924cce039e6d65add374f456ffb
To fix these inconsistencies, add a new upscript with the exact same
details as in 15418.up including the latest adaptations and a 'DROP
PROCEDURE IF EXISTS.
(cherry picked from commit 41769aa2a0)
Change-Id: I9a3d2373954326b2f6786dc8c5c27fc58cb73c44
* when ngcp-update-db-schema run and during the run the site_id
column is added, the site_id is set for all scripts that were
applied during the run before the 15867.up. It does not affect
scripts there were applied previously and site_id remains as NULL
for them, so they are considered as "already available globally".
Change-Id: If62af77a8e0f2ffa9c8fe54c195d6dc97c27c261
The new column store a value 0 or 1 to define wether the
ncos is applied when the time_set matches or not.
Change-Id: I65a8085afc61f0607fc90521015a4ceef11adc7b
The new column allows to store the label to show on the
deskphone's displays for the line types 'speeddial', 'forward' and
'transfer'.
Change-Id: I1323a4ac941b9ed15aa0bbd4ed59f387b8349b12
* add column ngcp.db_schema.site_id that is for multi site environments
and defaults to 1.
* the column is relied upon by ngcp-update-db-schema, mainly
to apply not_replicated scripts on sites with the different
site_id but same node name.
* site_id is only inserted for db nodes and otherwise left as NULL
* site_id=NULL means that the revisions are also meant for for both
sites (for ngcp-upgrade scenarios)
* ngcp-update-db-schema improvements:
- add site_id support
- config.node_roles key is now stored as-is and values
are converted as following:
* "yes"/"no" -> boolean True/False
* true/false -> boolean True/False
* else -> string
- check_release_column_exists() is reworked to
check_column_exists(column_name: str)
- fix except cause in main() to return error with the
stack trace as RuntimeError, instead of Exception
(as the latter returned only the error value).
Change-Id: I7c92b37db6562fa39f90a748fc567b100a8d9334
COLR = 'Connected line identification restriction'.
If set to true, the CLI is not displayed to the repmote
party on incoming calls.
Change-Id: I6e41534d8bc5d222f1d19dff1b809869ee9d951d
Add "ON UPDATE CASCADE ON DELETE CASCADE" to the ALTER statement
to fix issue with other down scripts failing to delete the
corresponding voip_preferences_enum entries due to this missing
parameter in 15787.down script.
Change-Id: I6bb91e9c0ea5f03c774ff826e8a29c0f5635eaaf
The new handle contains the announcement that will be played
to the calleer when the callee has the preference 'dnd' activated.
Change-Id: Id3201e9d2ae6ecb56fd858558d0a20d790306033
The down script tries removing some triggers from the wrong database,
add "USE provisioning" to fix it.
Change-Id: I407fde403aa5ee0a87282db0cf53d57d11155422
* shared entries now correctly mutually exclude entries with the same
numbers that are defined by subscribers (goes by precedence).
* add own field to contract and subscriber phonebook views to
identify if the entry was created by the subscriber/contract_id
or inherited.
Change-Id: I5494974b3c16026bb718f9a499e4b25e6b56e4ad
2-Factor-Authentication (2FA) for subscribers based on
voip_preferences only, to support lazy OTP secret initialisation
by application logic.
Change-Id: I265fe1c6e5b75d96aa77b6169ac7508bbf65fbb3
/usr/bin/mysql_install_db: Deprecated program name.
It will be removed in a future release, use 'mariadb-install-db' instead
Change-Id: I09bb289708c513d4ee0a229a6b1f859e064cfea2
The schema files contains '1970-01-01 00:00:01' as the value for timestamp
columns but when the sql file is uploaded into mariadb it's converted
according to time-zone settings and causes '0000-00-00 00:00:00' value
and warning 'Out of range value for column'.
So set session time zone UTC.
Change-Id: I6e5634df12104e2887142ace77df574c4200179c
Fix of db-schema.git:29ce6639d6a5101bf008274b678f022a449ca8e0 commit.
Instead of using string '1970-01-01 00:00:00' use
FROM_UNIXTIME(1).
Using the string causes the date '0000-00-00 00:00:00' and the warning:
+---------+------+-----------------------------------------------------+
| Level | Code | Message |
+---------+------+-----------------------------------------------------+
| Warning | 1264 | Out of range value for column 'applied_at' at row 1 |
+---------+------+-----------------------------------------------------+
It's because the time zones differences so '1970-01-01 00:00:00'
translates into earlier date which is out of range for timestamp
datatype.
Using the FROM_UNIXTIME() gives us a reliable result which fits the
datatype and is not zero date.
Change-Id: Ie123363a74e81c37c8ca5458b6aafd53fd3b74ca
This reverts commit 29ce6639d6.
Reason: setting timestamp fields as '0000-00-00 00:00:00' causes
API v1 ORM to read them as undefined and breaks the related logic as
either create_timestamp or modify_timestamp are expected to be
valid datetime strings.
Change-Id: I48ac4daa2e63727b6aa16314d9427ba4833937aa
Update columns with default 'current_timestamp()' to zero unixtime.
Update encrypted password and hashes to the current value,
Change-Id: I177d0f51437678526b0ae84fa916dafaa1dbf0ec
- use coalesce(unix_timestamp(if(x)),if(x)) rather than
coalesce(unix_timestamp(if(x)),0)
- fix from_unixtime(0) also in transform_billing_mappings()
in 15418.up
Change-Id: I55a54deb9e6e3412650e56cefed87a6637a2c0d1
* _effective_start date is now correctly becomes 0 if undefined
to address the general from_unixtime() change in MariaDB 11.5
that requires a value.
* the fix is taken from:
e935ac42 2025-04-29 MT#62676 fixes for mariadb 10.8/debian trixie [Rene Krenn]
Change-Id: I01cf96af3095fbf6e3cb9def9ddeb6c1f1883929
base/8629.up introduced voip_preferences_enum with auto
named foreign key as
"FOREIGN KEY (preference_id) REFERENCES voip_preferences (id)"
which auto created a missing index as
`preference_id` (`preference_id`).
diff/15787.up re-created the foreign key as named
"ADD CONSTRAINT `pref_id_fk` FOREIGN KEY (`preference_id`) ... "
which normally should cause the auto created `preference_id` key
to be renamed to `pref_id_fk`.
but customers who had their database re-synced, had that index
turned from "auto created" to "permanent" and therefore, causing
diff/15787.up to keep the original index name as `preference_id`.
that in turn, caused ngcp-mysql-compare-dbs to report db inconsistencies
as the default schema/.sql files are built with `pref_id_fk`.
the current fix addresses the index issue by dropping it as either
`preference_id` or `pref_id_fk` and creating it as a named index
`pref_id_idx`, so that it wont be affected by the issue anymore.
Change-Id: I4c777902251f915a1b07e92744d78e81087d607c
* fix peering hosts weight update to be correctly performed
only for the same peering host (was for the whole peering group).
Change-Id: Iaca327b1d49f2e50f9aa258e72392ffafe271fd3
* recreate provisioning.voip_phost_*_trig triggers with the same
content to fix a possible discrepancy caused by
15783_not_replicated.up
Change-Id: Id184e50c94ba9f92eb4ba6d243457e0343353704
* triggers are removed from the not replicated script because
they create an issue if this script is applied on the other
node after 15791.up and 15797.up and revert the triggrs to
inintended state.
Change-Id: Iac830c24d0d51d693e6dbe76cea3766feebf7dd8
Sipwise Jenkins Builder
Kirill Solomko
Jose Su
Marco Capetta
Fabricio Santolin da Silva
Rene Krenn
Mykola Malkov
Richard Fuchs
Guillem Jover
Victor Seva