Timas

INACT for Timas. Not in the big five since 2026-09-14: a fix is ported here only when its own work item asks for it. Timas was in the default set from 2026-09-02 to 2026-09-13, so verification notes dated in that window that name "big five" include it. It is still a maintained instance with a live test database. Not the same client as KTP or JOTRE.

At a glance

Jira	INA14, Timas
INA05 INACT Instance value	Timas
Repository	binari-digital/ina-timas. Renamed on 2026-08-23 from inact-timas.
Encrypted twin	binari-digital/ina-timas-encrypted
INARTS GitLab	inact/inact-timas, plus the encrypted twin
Permanent branches on origin	main, development. No staging.
Database	MySQL
Production	edms.timas.com, the client's own server, on premise. Pulls from INARTS.
Staging	none
Dev (QA)	inact-timas-encrypted.bdt.dev on the Rumah box

TODO: production MySQL version.

Repositories and remotes

Measured on 2026-08-24 across 26,483 tracked files: main.php is the only file that differs between the plain repository and the encrypted twin.

Environments and deploy

Push to	Script	What happens
development	deploy/dev.sh	Sync plain to encrypted, push both to GitHub and INARTS. The consumer pulls ~/www/inact-timas-encrypted on the Rumah box and runs phinx migrate.
main	deploy/prod.sh	Sync plain main to encrypted main, push to GitHub and INARTS. Timas has a real production consumer, unlike Jadestone and JOTRE. The push to GitHub fires deploy/prod.sh in the encrypted twin, which ssh's to [email protected], pulls /home/admintimas/www/inact from INARTS and runs phinx migrate.

The client box's origin is the INARTS GitLab, inact-timas-encrypted.git, not our GitHub. So the push to inarts is the one that reaches the client, and the push to origin is the one that fires the consumer.

Database

Driver	MySQL
QA database	MySQL on the Rumah box itself, database inact_timas_encrypted
Test database	Shared dev DB host 192.168.1.52, port 3357, database inact_timas_eris

How this fork differs from master

Measured on 2026-09-05.

Module files that differ	116
Modules with the most changes	dms_reference 16, routing 15, documents 14, documents_master 11, adms 8, member 7, adms_reference 7
Libraries that differ	additional_global_variables.inc.php, inweb.lib.php, reference_function.inc.php, tracking_function.inc.php
Top-level files that differ	auto_logout.php, setting.php
Migrations	391 in total. 5 only here, 45 in master not taken. Newest 2025-12-26.

Files only in this fork

• modules/documents_master/documents_master_handler_print_overdue_report.php
• modules/reference/system_code.php

Two backup copies of the multi-upload handler also sit in modules/documents_master/.

Files in master that this fork lacks

• modules/adms/adms_rev_sort.inc.php
• modules/adms_reference/adms_reference_import.inc.php
• modules/dms_reference/auto_doc_numbering.php
• modules/dms_reference/autopublish_auto_folder_creation.php
• modules/dms_reference/doc_classification.php
• modules/dms_reference/function_code.php
• modules/dms_reference/retention.php
• modules/dms_reference/system_code.php
• modules/dms_reference/watermark_settings.php
• modules/dms_reference/well_site.php
• modules/documents/export_excel.php
• modules/documents/json/

inweb_config keys

	Keys
Only in this fork	enable_publish_to_correspondence, enable_routing_slip
Missing here	autopublish_auto_folder_creation, consolidated_routing_view, enable_auto_doc_numbering, enable_doc_classification, enable_doclib_retention, enable_last_login_wins, enable_ldap_browse, enable_ldap_login, enable_return_on_audit, enable_routing_notif_digest, enable_routing_overdue_notif_digest, enable_system_code, enable_watermark, enable_well_site, inact_operator_role, routing_notif_digest_hour, routing_return_format

Customizations documented so far

None yet. Feature pages arrive in phase 3 of the docs plan.

Known gotchas

• Far behind master. 45 master migrations and a whole set of DMS reference features (auto numbering, classification, retention, watermark) are not here. A port from master often needs its prerequisites ported first.
• Production migrates itself. The prod consumer runs phinx migrate on edms.timas.com. A migration merged to main reaches production on the next deploy, so a data-changing migration needs to be safe to run unattended.
• No staging branch at all. Do not open a [staging] PR here.