Download the PHP package remp/crm-application-module without Composer

CRM Application Module

Configuration

Redis

You can configure default Redis keys prefix, which is used if implementation using RedisClientTrait enables prefixing via useRedisKeysPrefix() method.

You can turn on prefixing for specific service using RedisClientTrait by calling useRedisKeysPrefix() method in configuration.

Replication

CRM supports Redis replication with use of Redis Sentinel. To enable the use of sentinel, add following to your config.neon:

Database

Replication

CRM allows you to configure secondary database connections used for read-only queries to lower the load of the primary database server. Add these blocks to your CRM configuration:

Commands

application:heartbeat

If your Hermes worker (application:hermes_worker) is losing connection to MySQL after a long period of inactivity, add application:heartbeat into your scheduler (e.g. crontab) with small interval (e.g. 1 minute).

WARNING: Change paths to PHP and command.php according to your installation.

Event is handled by HeartbeatMysql handler which pings MySQL. This simple process keeps Hermes worker alive.

application:hermes_shutdown

Command application:hermes_shutdown can be used to gracefully shutdown Hermes worker and all other workers which integrate Hermes' RestartInterface (eg. Scenarios worker present in ScenariosModule). This can be used after CRM update when it's needed to reload all workers to new version.

WARNING: Change paths to PHP and command.php according to your installation.

User confirmation is required to proceed with shutdown of all worker.

In case you need to run this command without user interaction (eg. CI, tests), use --assume-yes flag:

application:cleanup

Command can be used to clean up data from repositories, which you don't need to keep forever (i.e. logs).

By default, the command deletes data older than 2 months (based on the created_at column). You can change the default threshold time before which the command deletes old repository data, and also column which it uses by using (in your project configuration file):

Components

FrontendMenu

User-facing frontend menu expected to be used in your application layout.

FrontendMenuDataProviderInterface

Interface which dataproviders have to implement to be able to edit FrontendMenu items. Dataproviders have to be attached to frontend_menu dataproviders placeholder.

Graphs

Following is a set of various charts provided by the ApplicationModule out of the box.

GoogleBarGraph

Simple bar graph based on Google charts. Usually used within GoogleBarGraphGroup component, but can be also used separately if you need to manage your groups (keys within $data parameter) manually.

GoogleBarGraphGroup

Simple bar graph based on Google charts. Component is able to create multiple groups based on ->setGroupBy method and results of your query. Internally uses GoogleBarGraph to render the chart.

GoogleLineGraph

Simple line graph based on Google charts. This component is only being used by GoogleLineGraphGroup and is not advised to be used directly unless you really need to provide raw data for the chart.

GoogleLineGraphGroup

Simple line graph based on Google charts. Component is able to create multiple series based on data grouped within built query.

InlineBarGraph

Inline bar chart is meant to be used directly within grids or with other inline bar charts to provide quick information about the data.

SmallBarchart

SmallBarChart is targeted to be used within widgets across the CRM admin, but can be also used in user-facing frontend to provide simple countable information.

GoogleSankeyGraphGroup

A sankey graph is a component based on Google Sankey diagram. It's used to depict a flow from one set of values to another.

VisualPaginator

Paginator is used to limit and offset your results displayed in lists all around the system. Paginator keeps the current page/limit and provides the information to your data-fetching blocks of code.

Widgets

Following is a set of widget wrappers provided by ApplicationModule to be used by your widgets. Application provides three set of wrappers:

SimpleWidget

Simple widget is the component allowing simple extension of modules's view by other modules. Module can provide placeholder for widgets in the action's template (in .latte file) and other module can register their implementations of widget in their Module class.

You can read more about creating and registering widgets in CRM skeleton documentation available at github.com/remp2020/crm-skeleton.

SingleStatWidget

Widget provides wrapper for simple table with single statistic - each provided by separate widget implementation. The primary scenario for this use are dashboards.

Database tables migration

Because of need of changing primary keys (int -> bigint), in tables that contain lots of data (or have risk of overflowing primary key if its int), we had to create migration process. Since some tables are very exposed and cannot be locked for more than a couple of seconds, we decided to create new tables, migrate the data manually and keep the old and new table in sync while migrating.

This migration process is necessary only for installations after specific version for specific table, and is two steps process.

Audit logs migration (installed before 2.5.0)

Consists of audit_logs table migration.

Steps:

1. Run phinx migrations command phinx:migrate, which creates new table audit_logs_v2 (in case there is no data in table, migration just changes type of primary key and next steps are not needed).
2. Run command application:convert_audit_logs_to_bigint, which copies data from old table to new (e.g. audit_logs to audit_logs_v2). Command will after successful migration atomically rename tables (e.g. audit_logs -> audit_logs_old and audit_logs_v2 -> audit_logs), so when the migration ends only new tables are used.

It's recommended to run application:bigint_migration_cleanup audit_logs command, at least 2 weeks (to preserve backup data, if some issue emerges) after successful migration to drop left-over tables.