Note: Migrations should be performed offline. Failing to perform an online migration, the option provided below will not be available if the migration crashes. Running the below commands to reset the database for the migrations to re-run will cause data loss if users are making changes to Centurion.
-
History views removed from original Centurion interface.
-
History views removed from API v1.
-
A migration exists that will move the history from the old tables to the new ones.
if for some reason the migration crashes enter the following commands in the dbshell
python manage.py dbshell
and restart the migrationsdelete from access_organization_history; delete from access_team_history; delete from assistance_knowledge_base_history; delete from assistance_knowledge_base_category_history; delete from config_management_configgroups_history; delete from config_management_configgroupsoftware_history; delete from config_management_configgrouphosts_history; delete from core_manufacturer_history; delete from core_ticketcategory_history; delete from core_ticketcommentcategory_history; delete from itam_device_history; delete from itam_devicemodel_history; delete from itam_devicetype_history; delete from itam_deviceoperatingsystem_history; delete from itam_devicesoftware_history; delete from itam_operatingsystem_history; delete from itam_operatingsystemversion_history; delete from itam_software_history; delete from itam_softwareversion_history; delete from itam_softwarecategory_history; delete from itim_cluster_history; delete from itim_clustertype_history; delete from itim_port_history; delete from itim_service_history; delete from project_management_project_history; delete from project_management_projectmilestone_history; delete from project_management_projectstate_history; delete from project_management_projecttype_history; delete from settings_externallink_history; delete from core_model_history;
The above commands truncate the data from the new history tables so the migration can run again.
- Nothing significant to report
- Nothing significant to report
- Prometheus exporter added. To enable metrics for the database you will have to update the database backend. see the docs for further information.
- When v1.4.0 was release the migrations were not merged. As part of the work conducted on this release the v1.4 migrations have been squashed. This should not have any effect on any system that when they updated to v1.4, they ran the migrations and they completed successfully. Upgrading from <1.4.0 to this release should also have no difficulties as the migrations required still exist. There are less of them, however with more work per migration.
!!! Note If you require the previously squashed migrations for what ever reason. Clone the repo and go to commit 17f47040d6737905a1769eee5c45d9d15339fdbf, which is the commit prior to the squashing which is commit ca2da06d2cd393cabb7e172ad47dfb2dd922d952.
API rede# preparation for moving the UI out of centurion to it's own project. This release introduces a Feature freeze to the current UI. Only bug fixes will be done for the current UI. API v2 is a beta release and is subject to change. On completion of the new UI, API v2 will more likely than not be set as stable.
-
A large emphasis is being placed upon API stability. This is being achieved by ensuring the following:
-
Actions can only be carried out by users whom have the correct permissions
-
fields are of the correct type and visible when required as part of the API response
-
Data validations work and notify the user of any issue
We are make the above possible by ensuring a more stringent test policy.
-
-
New API will be at path
api/v2
. -
API v1 is now Feature frozen with only bug fixes being completed. It's recommended that you move to and start using API v2 as this has feature parity with API v1.
-
API v1 is depreciated
-
Depreciation of ALL API urls. API v1 Will be removed in v2.0.0 release of Centurion.
!!! danger "Security" As is currently the recommended method of deployment, the Centurion Container must be deployed behind a reverse proxy the conducts the SSL termination.
This release updates the docker container to be a production setup for deployment of Centurion. Prior to this version Centurion ERP was using a development setup for the webserver.
-
Docker now uses SupervisorD for container
-
Gunicorn WSGI setup for Centurion with NginX as the webserver.
-
Container now has a health check.
-
To setup container as "Worker", set
IS_WORKER='True'
environmental variable within container. Note: You can still use commandcelery -A app worker -l INFO
, although not recommended as the container health check will not be functioning
Initial Release of Centurion ERP.
- Nil