Various improvements and bug-fixes respect v5.10-dev. In particular:
- importing of CDRS on remote MySQL databases
- generation of reports without wasting RAM
- improvements to the manual
- minor improvements to the user interface
- bug fixes
It is used in production, but it is still considered "test" because there are a lot of changes respect last stable version, and not all features are covered by regression tests.
Upgrading from v5.10-dev
If you installed the previous dev version, you can not upgrade it, but you had to reinstall this version from scratch. In case you have data to preserve, you can backup the DB and restore it in the new version, because there are no changes in the DB schema. You can use
php asterisell.php data backup.
In case you are installing on the same VM, you had to delete the Asterisell tag files, for forcing a reinstallation from scratch:
Migrating from v5.9 (last stable) to v5.10.2-test
This version changed a lot of things respect last stable version v5.9. In particular the instances are now installed directly on the host/VM, and not anymore inside a Docker container. The management tool is installed on a Docker container.
There is no automatic upgrade like in case of previous release changes. It is more a migration than an upgrade, also if in the end all the data can be transferred.
These are notes on how performing the upgrade, but for understanding them you had to install at least a DEMO version of Asterisell-5.10, otherwise some notes can be too much obscure.
- source-host: the host containing the instance to migrate
- source-instance: the instance to migrate
- host: the target host on which install the instance
- instance: the target instance
- management-host: the host containing the Asterisell management tool (it can be also on host)
- asterisell-deploy: the directory of Asterisell management tool (source and dest)
host/instance and make sure to not execute cron_job on
host/instance, adding this setting in the instance class
install_cron_job = False
Then install using
Now we can start migration, because we have both source and dest-instance.
# Copy the migration scripts on source-instance ssh some-user@host cd scripts/migration_to_v10 scp pass-01-export.sql some-user@source-host:. # Extract the data from source-instance and send to host ssh some-user@source-host cd asterisell-deploy docker cp ../pass-01-export.sql source-instance:. fab connect:source-instance php asterisell.php cron disable rm -f /var/tmp/*.csv cat config/databases.yml # for findng access passwords mysql -usource-instance -ppassword source-instance < /pass-01-export.sql cd / tar cfvz db-instance.tar.gz /var/tmp/*.csv rm -f /var/tmp/*.csv scp db-instance.tar.gz some-user@host:. rm db-instance.tar.gz exit # Go to management-host. fab connect:asterisell/instance cd /var/tmp rm -f *.csv tar xfvz /home/some-user/db-instance.tar.gz mv var/tmp/*.csv . rm /home/some-user/db-instance.tar.gz cd /var/www/instance/admin/scripts/migration_to_v10/ # check access params with cat ../../config/databases.yml mysql -uinstance -ppassoword instance < pass-02-import.sql rm -f /var/tmp/*.csv cd .. cd .. php asterisell.php data update-cached-cdrs exit # Now we are again in managemnt-host # and we enable again triggers, # that were deleted by pass-02-import.sql fab upgrade_conf:asterisell/instance
If source-instance has custom holidays set, you had to specify them also in the destination instance, because they are not ported automatically.
If source-instance uses bundle-rates, you had to modify them, removing lines like
You had to copy the LOGO of the source-instance, and upload it again in the instance:
using the Web UI
copying the file into directory
Now you can activate again cron-jobs, removing the
install_cron_job in the Instance configuration file, and then
VoIP extension codes
Asterisell 5.11.1 uses simpler extension codes. It is unlikely, but there can be incompatibilities, and some extensions had to be converted to the new format. In this case it is likely that the application will not recognize these old extensions any more, and it will signal the problem during the rating process.
The new extension format is simpler: "X" and "*" can be used only at the end of extensions and not any more in the middle. So:
- in "12XX" the last "X" stays for "match any character"
- in "1X2" the "X" is not a special symbol, and it matches exactly the "X"
- "12*" matches any extension starting with "12"
- "12" is exactly the "12" extension
The version with "X" and "*" in the middle were not used in practice, and now we can use faster data structures in the code, during rating.
Importing CDRS from remote DBMS
The previous method was based on configuration of connections on
asterisell_instances.py file, and custom PHP Jobs retrieving data.
Now remote DBMS are directly supported by the Haskell rating engine, and all params are specified directly in connection params of
asterisell_instances.py, and there are no any more custom PHP jobs.
The new method is more robust and DBMS friendly, because it exploits the properties of auto increment field, and do not use transactions on remote databases, but only on local database.