Zymonic Toolkit

Introduction

For more information see manual entries at https://mq2-public.zednax.com/man/ztsm/#Toolkits

The toolkit is a comprehensive suite of diagnostic tools and system actions. This has been designed to ensure a consistent structure to all diagnostic and updates tools for zymonic systems, run via the command line. In this way many functions are now easier to perform via the command line than previously.

All zymonic_toolkit.pl functions are formatted one of the following ways:

zymonic_toolkit.pl [MODULE] [COMMAND] [COMMAND ARGUMENTS]
zymonic_toolkit.pl [CONFIG FILE]

The MODULE element of the format is the category of command to be used. A list of the current available MODULES can be found on the manual index

If zymonic_toolkit.pl [MODULE] is entered on the command line the COMMANDs which are available for use, within that category of the toolkit, are listed. For example, if 'zymonic_toolkit.pl System' was to be entered on the command line, amongst the list of available commands will be 'create_admin - the ability to create an admin users for your zymonic system.'

The COMMAND element of the format is the function. If zymonic_toolkit.pl [MODULE] [COMMAND] is entered on the command line the options that are available for use in conjunction with the chosen command are listed. The list of available COMMAND ARGUMENTS will be displayed together with a brief description and if they are required for the function to be carried out successfully. For example, if 'zymonic_toolkit.pl System create_admin' was to be entered on the command line, amongst the list of available COMMAND ARGUMENTS will be '--username - Username - The username of the user (defaults to admin).'

The COMMAND ARGUMENTS element of the tookit format encompasses all the options that can and should be used to carry out the required function. Each COMMAND ARGUMENT is separated with a space. For example to create an admin user, via the command line 'zymonic_toolkit.pl System create_admin --system SYSTEM --username USERNAME'

The CONFIG FILE variant can be used when there are a lot of COMMAND ARGUMENTS. All of the above; the MODULE and COMMAND, together with all the COMMAND ARGUMENTS can be put into an xml file using the following format:

<ZymonicToolkitConfig>
  <module>MODDULE</module>
  <method>COMMAND</method>
  <COMMAND_ARGUMENT_1>...</COMMAND_ARGUMENT_1>
  <COMMAND_ARGUMENT_2>...</COMMAND_ARGUMENT_2>
  ...
  <COMMAND_ARGUMENT_N>...</COMMAND_ARGUMENT_N>
</ZymonicToolkitConfig>

Data

For more detailed information on the Data module, please click here. If you have never used this before, it is advised that you read the full documentation.

• Check Database for Valid Characters

  Checks tables and fields for invalid characters - if no table or field are specified the command will process the whole DB or table.

• Clean Database

  Removes autocreated records, deleted records and handles orphan records from tables in system.

• Help

  When using a terminal to run zymonic_toolkit.pl the user will see prompts that contain the same information that is found within this manual.

Debugs

For more detailed information on the Debugs module, please click here. If you have never used this before, it is advised that you read the full documentation.

• Convert to SQLite

  Converts a debug log to an SQLite file usable by zymonicdebugs

• Help

  When using a terminal to run zymonic_toolkit.pl the user will see prompts that contain the same information that is found within this manual.

Decryptor

For more detailed information on the Decryptor module, please click here. If you have never used this before, it is advised that you read the full documentation.

• Import Ecommerce Keys

  Imports keys from e-commerce and sets the keyversion to a

• Ping

  Pings the decryptor(s)

• Help

  When using a terminal to run zymonic_toolkit.pl the user will see prompts that contain the same information that is found within this manual.

Definition

For more detailed information on the Definition module, please click here. If you have never used this before, it is advised that you read the full documentation.

• Build

  Builds the cache for a system definition

• Export Definition

  Gets the definition of a Zymonic object or objects including defs for any fields, keys or permissions referenced by zname

• Get Definition

  Gets the definition of a Zymonic object or objects

• Import from Database

  Imports from the database as XML

• Help

  When using a terminal to run zymonic_toolkit.pl the user will see prompts that contain the same information that is found within this manual.

Email

For more detailed information on the Email module, please click here. If you have never used this before, it is advised that you read the full documentation.

• Email Handler

  Allows incoming emails to be parsed and processes created from the data within.

Installer

For more detailed information on the Installer module, please click here. If you have never used this before, it is advised that you read the full documentation.

• Combine Stylesheets

  Combines the stylesheets for Zymonic Blocks to load dynamically - this is usually automatically done by the installer, this command is primarily for testing the XSL combiner set-up.

• Install

  Installs the parts of Zymonic not installed by the perl Makefile.PL, i.e., Javascript, XSL stylesheets, configuration etc.

• List Manifests

  Lists the currently installed manifests - handy for replicating machine set-up.

• Update

  Updates the repositories associated with the selected manifests.

• Update and Install

  Updates the repositories associated with the selected manifests.

• Help

  When using a terminal to run zymonic_toolkit.pl the user will see prompts that contain the same information that is found within this manual.

Locking

For more detailed information on the Locking module, please click here. If you have never used this before, it is advised that you read the full documentation.

• Action Required Locks

  Returns list of locks which would be required to run the action.

• Process Required Locks

  Returns list of locks which would be required to change this process at its current state.

• Transition Required Locks

  Returns list of locks which would be required to run the transition.

• User Locks

  Returns list of locks a user currently holds.

• Help

  When using a terminal to run zymonic_toolkit.pl the user will see prompts that contain the same information that is found within this manual.

System

For more detailed information on the System module, please click here. If you have never used this before, it is advised that you read the full documentation.

• add_defaults

  Adds default lists, records and processes to the system

• add_parent_processes

  Adds parent processes to any item in the table or tables (if table parameter is not set, all tables will be processed) which have a parent_process_id of NULL

• build_documentation

  Builds documentation for the system

• build_object_caches

  Causes an object (if specified) or all objects to build their cache or caches.

• check_for_deprecation

  Checks for deprecation in the system's xml

• check_for_optional_dependencies

  Checks for optional dependencies

• check_for_performance_issues

  Checks for performance issues

• check_for_security_issues

  Checks for security issues

• combine_stylesheet

  Combines the current stylesheet for the system (if necessary).

• config_build

  Builds or updates the system's definition cache and then runs: check_for_security_issues, update_db_structure, update_pages, update_roles, add_defaults, update_table_security and update_fap

• create_admin

  Creates an admin user

• detect_record_security_modes

  For each table, detects whether they're using the new or old record security mode.

• detect_update_times

  For each table, calculates average update time based on zzlu, and sets a flag used to determine how often to refresh materialized views.

• drop_materialized_views_table

  Zymonic Filters cache there data in Materialized Views. These are then managed via a table in the DB. This will drop that table forced it to be recreated the next time it is needed.

• dump

  Dumps the contents of the system either to file, or sends to another system

• get_sys_opt

  Takes a system and option name and returns the value of the system option.

• import

  Import the contents of a system dump, either from a file or sent from another system

• process_missing_mappings_from_import

  During import there can be mappings between tables which were not able to be set during the import itself, this will process all such missing mappings. This will be automatically run if importing dump files, once all files have been imported. Should only need to be run explicitly if importing in chunks via API calls, then it should be called after final import call.

• remove_orphaned_blocks

  Removes any blocks from the system which containg filters or process which have been removed or made unavailable.

• remove_orphaned_role_permissions

  Removes any blank lines from roles, these are role permissions which have been removed or made unavailable.

• synchronize_csv

  Uploads, updates and/or deletes data from a csv into a table. Include full path to csv, zname of the table, and the sequence of field znames as they are in the csv file.

• update_db_structure

  Updates DB structure

• update_fap

  Updates the list of filters and processes.

• update_pages

  Updates the pages in the DB

• update_roles

  Updates the roles in the DB

• update_table_security

  Updates permissions that apply at table level (not record level).

• update_version_number

  Determines the current version of the system and updates the system to display it

• update_zzlu_on_all_tables

  For each table in the system, ensures the last updates timestamp of each record (zzlu and zzluts) is not null.

• upload_csv

  Uploads data from a csv into a table. Include full path to csv, zname of the table, and the sequence of field znames as they are in the csv file.

• validate_system_options

  Checks if the current and default values of all system options pass validation. Those that pass are flagged as being validated and only those missing that flag are checked on subsequent runs.