Working on a ticket

The path from a Jira work item to a merged change, for INACT specifically. The company-wide rules, commits, branches and pull requests, are in Standards; this page adds what is different because INACT is one code base forked per client.

How this page was verified

Repository and branch facts were read from the remotes on 2026-09-05 and 2026-09-06. The Jira mapping is the team's working map.

1. Find the instance

Every INACT ticket belongs to one instance, and the instance decides the repository, the branch model and the test database.

Jira project	Instance	Repository
INA01	Master (INACT v3)	inact
INA27	Jadestone	ina-jadestone
INA28	Medco	ina-medco-v3
INA36	JOTRE	ina-jotre
INA14	Timas	ina-timas
INA12	Tomori	ina-tomori
INA10	KTP	ina-ktp
INA05	INACT Support: any instance	the one the item names

INA05 is the cross-instance project. Every item there comes from an INARTS support ticket, its summary starts with that ticket's id in round brackets, and its INACT Instance field names the instance. Because these are defects on live instances, the same defect usually exists in the sibling forks too.

Three clients carry "Timas" in their name and are three different repositories: Timas, KTP and JOTRE. Check the project key, not the name.

2. Check the branch model

Read it from the remote, never from memory:

git ls-remote --heads origin

Instance	Permanent branches	What that means
Master	main only	commit straight on main, no work-item branch, no PR
Jadestone, Medco, JOTRE, KTP	main, staging, development	work-item branch cut from origin/main, one PR per target
Timas, Tomori	main, development	same, without a staging PR

Medco and JOTRE have a staging branch, but their deploy workflow does not deploy it. Merging there changes nothing on any server. The rest of the branch and PR rules are on the Git Workflow standard.

3. Is the feature even there

The forks are near-identical, but they drift, and a feature that exists in one may be missing, renamed or dead in another. Before assuming, grep the sibling:

for d in /path/to/www/*/; do
  grep -rli "<feature>" --include="*.php" "$d" | grep -v /vendor/
done

Two traps that catch everyone:

• A function can exist and be dead. The legacy helper iw_mysql_query() throws on entry in master, Jadestone, Medco and Timas. Any path that still calls it dies there. JOTRE is the exception. The module pages list the affected paths per module.
• A config key can be in the seed and not in the live table, or the other way round. Confirm against the instance's database. Each instance page lists the seed differences.

4. Reproduce on the right data

Each fork's checkout points at a test database on the shared dev host, see Local setup. Master's test databases are nearly empty; a query that depends on a rarely filled table looks fine there and is still wrong in production. Medco's and Jadestone's snapshots are production copies and are the better place to try real data. When the ticket names a project code, that usually tells you which snapshot to use.

The screens are server-rendered pages with dhtmlxGrid on top. Grid sorting, dropdown contents and template wiring only show their real behaviour in a browser. Test the screen, not only the function.

5. Make the change portable

Every instance must run on MySQL, PostgreSQL and SQL Server. Use $pdo, never the legacy helpers, and follow the Database portability rules. A migration goes under db/migrations/ as a phinx class; seeds under db/seeds/.

6. Port it to the siblings

A generally useful fix 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. Timas, Tomori and KTP get a port only when their own work item asks for it. Do not apply the same diff blindly; find the equivalent anchor in each fork and adapt, because the files differ.

The clone relationship is recorded as a Jira link. Never put another project's work-item key in a commit or PR body; the GitHub for Jira app would attach the PR to the wrong ticket.

7. Commit, PR, deploy

Commit and PR rules are the company standards: ticket id in the subject, [target] prefix on PR titles, plain merges, the work-item branch lives until production. On INACT the extra facts are:

• Dev and staging deploy themselves. A push to development runs the producer, syncs the encrypted twin, and the consumer pulls the QA site and runs phinx migrate. Do not list "run the migration on dev" as an open task.
• Production is different per client. Some pull from INARTS, some get a release zip, one migrates itself. See Environments and deploy and the instance page.
• The encrypted twins are reference copies on a Mac. You never edit them; the deployer syncs them. Test an encoded build on the -encrypted.bdt.dev QA site.
• A change to main.php stops the sync until someone re-encodes it. Avoid touching it unless the ticket is about it.

8. Write it down

If the ticket touched a module that has no page in this hub, or changed something a page describes, the page is part of the ticket. Frontmatter carries last_verified and verified_on; update them. The contributing guide has the template.