INACT

INACT is a web application for engineering document control and project procurement. A project team registers its documents in a Master Document Register (MDR), routes them for review and approval, issues transmittals to the client, and keeps the approved copies in a Document Library. Version 3 adds procurement, cost control and asset modules: RFQ, purchase order, invoice, budget, equipment.

Binari develops and maintains it for several clients. Every client runs its own copy, called an instance. Commercially it is sold as three module groups: DMS, the document management core every client has; Procurement, which only some clients switch on; and Cost Control & Budgeting, which sits on top of Procurement. The instance comparison says who has what.

Stack

Language	PHP 7.3 or newer, no full-stack framework
Pages	Server-rendered PHP templates, dhtmlxGrid for the grids
Database	MySQL, PostgreSQL or SQL Server. One code base, all access through PDO
Schema	phinx migrations and seeds under db/
Libraries	Slim 4, illuminate/database, PhpSpreadsheet, HTML2PDF and TCPDF, PHPMailer, all through Composer
Background jobs	PHP scripts under cron/, started by crontab

The fork model

The master repository is binari-digital/inact, Jira project INA01. It is also mirrored on the INARTS GitLab as inact/inact-v3-master.

Each client gets a repository forked from the master. The forks are near-identical: the same 54 modules, the same libraries, the same seeds. They drift over time as client-specific work lands, but the differences sit inside features, such as a config key, a gate or a changed handler, not in whole modules. Measured on 2026-09-05: between 93 and 178 module files differ from master per fork, out of about 2,900.

What follows from that:

• A fix that is generally useful is made in one instance, then cloned as a work item into each sibling's Jira project and ported repository by repository. The default port set is the big five: master, Jadestone, Medco, JOTRE and Prima Energy.
• Never assume a feature exists in a fork because it exists in another one. Grep the sibling first.
• Every change must work on all three database drivers, because the instances really do differ.

Encrypted twins

Clients receive an ionCube-encoded build. Each such instance has a *-encrypted repository that holds the encoded build and is mirrored to the INARTS GitLab. The encoded build cannot run on an Apple-silicon Mac, so those checkouts are reference copies only. Testing an encoded build happens on the shared QA sites.

Instances

All repositories live under binari-digital on GitHub.

Client	Jira	Repository	Encrypted twin	Database
Master, INACT v3	INA01	inact	—	all three
Jadestone	INA27	ina-jadestone	ina-jadestone-encrypted	MySQL
Medco	INA28	ina-medco-v3	ina-medco-v3-encrypted	SQL Server
JOTRE, Joint Operation Timas and Rekind	INA36	ina-jotre	ina-jotre-encrypted	MySQL
Timas	INA14	ina-timas	ina-timas-encrypted	MySQL
Tomori	INA12	ina-tomori	ina-tomori-encrypted	SQL Server
KTP, KSO Timas Pratiwi	INA10	ina-ktp	—	MySQL

The database column is the driver each instance is configured for in its .env. Hosting, environments and the code differences are on each instance page.

Three clients carry "Timas" in their name

Timas (INA14), KTP (INA10) and JOTRE (INA36) are three different clients with three different repositories. Check the Jira project before you touch a repository.

INA05, INACT Support, is not tied to one instance. Every item there comes from an INARTS support ticket and names the instance in its INACT Instance field. Because these are defects on live instances, the same defect usually exists in the sibling forks too.

Older instances exist as well, such as Berca, Prima Energy and BWS. They are not in the default port set and get a page only when work touches them.

Where to go next

New here: Local setup, then the codebase tour, then working on a ticket. Assigned to a client: its instance page. Touching a module: its page under Modules, and the contributing guide when the page does not exist yet.