Upgrade 3.21: различия между версиями

Материал из WiKi - UserSide
([IronBot] Update UK language link)
([IronBot] Sync EN localization from RU)
Строка 6: Строка 6:


== A Few Words from the Author ==
== A Few Words from the Author ==
*
 
* An architectural transition has been made from numeric object identifiers ''(ID)'' to string identifiers ''(UUID)''. For many object types, the old ID remains available for convenience ''(for example, "Task No.7562" is easier to use than "Task No.ae4ae420-7643-4572-a752-9ecfdbeca371")''. Internally, the database and core now bind records by UUID. Among other things, this will make it possible later to merge several systems into one if needed. '''Important''': because this ID/UUID migration affects almost the entire database ''(often more than once)'', run FULL VACUUM after the upgrade finishes. Without this step, the system will work very slowly. Also note that on a large database, '''the upgrade/migration may take hours'''.
 
* A deep UI/UX refactoring and update has been completed. The separate "mobile version" has been removed, with emphasis placed on a comfortable interface on mobile devices.
 
* The mechanics of the [[Switching scheme|switching scheme]] have been reworked: display is 2-10 times faster, and commutation in the scheme no longer reloads the page. Also note that [[Hotkeys|hotkeys]] are available and can speed up work even more.
 
* The [[Internal API EN|Internal API]] v2 event system has been added/reworked/documented. Version v1 ''(custom_api.php)'' is still supported, but you should gradually move to v2.
 


* [[Upgrade]]. '''I recommend having two system instances''': a production instance and a separate test instance. On the test instance, you can periodically refresh the database from the production system and run the upgrade there to make sure everything works, review new features, and identify anything that has stopped working for you.
* [[Upgrade]]. '''I recommend having two system instances''': a production instance and a separate test instance. On the test instance, you can periodically refresh the database from the production system and run the upgrade there to make sure everything works, review new features, and identify anything that has stopped working for you.

Версия от 14:58, 29 мая 2026

en | uk | ru

Version: 3.21

Required version: 3.12 and above

A Few Words from the Author

  • An architectural transition has been made from numeric object identifiers (ID) to string identifiers (UUID). For many object types, the old ID remains available for convenience (for example, "Task No.7562" is easier to use than "Task No.ae4ae420-7643-4572-a752-9ecfdbeca371"). Internally, the database and core now bind records by UUID. Among other things, this will make it possible later to merge several systems into one if needed. Important: because this ID/UUID migration affects almost the entire database (often more than once), run FULL VACUUM after the upgrade finishes. Without this step, the system will work very slowly. Also note that on a large database, the upgrade/migration may take hours.
  • A deep UI/UX refactoring and update has been completed. The separate "mobile version" has been removed, with emphasis placed on a comfortable interface on mobile devices.
  • The mechanics of the switching scheme have been reworked: display is 2-10 times faster, and commutation in the scheme no longer reloads the page. Also note that hotkeys are available and can speed up work even more.
  • The Internal API v2 event system has been added/reworked/documented. Version v1 (custom_api.php) is still supported, but you should gradually move to v2.


  • Upgrade. I recommend having two system instances: a production instance and a separate test instance. On the test instance, you can periodically refresh the database from the production system and run the upgrade there to make sure everything works, review new features, and identify anything that has stopped working for you.

Upgrade Notes

  • If you are upgrading from version 3.10, read this page: Upgrade 3.11
  • If you are upgrading from version 3.11 or earlier, read this page: Upgrade 3.12
  • If you are upgrading from version 3.12 or earlier, read this page: Upgrade 3.13
  • If you are upgrading from version 3.13 or earlier, read this page: Upgrade 3.14
  • If you are upgrading from version 3.14 or earlier, read this page: Upgrade 3.15
  • If you are upgrading from version 3.15 or earlier, read this page: Upgrade 3.16
  • If you are upgrading from version 3.16 or earlier, read this page: Upgrade 3.17
  • If you are upgrading from version 3.17 or earlier, read this page: Upgrade 3.18
  • If you are upgrading from version 3.18 or earlier, read this page: Upgrade 3.19
  • If you are upgrading from version 3.19 or earlier, read this page: Upgrade 3.20
  • Move/delete third-party files, directories, and other items from the userside directory. It must contain only the distribution files of the system itself and files created by the system during operation. UserSide modules (usm) also must not be stored there. Use separate directories for them, for example `/opt/userside`. Third-party files in the userside directory may be deleted during the upgrade.
sudo -u www-data php userside_install.phar install
  • Do not forget to update all modules to their latest versions.

Change list: view

Upgrade procedure: instructions