# cPanel deployment notes

This folder is the application payload for the `congregation_api` Node.js
application. Upload and extract its contents directly into:

`/home/vtfogphx/congregation_api`

The cPanel application must remain configured with:

- **Application mode:** Production
- **Startup file:** `dist/server.js`
- **Port:** do not configure one; cPanel supplies `PORT` automatically.

Before starting the application, create this environment variable through the
cPanel Node.js Application Manager:

- `JWT_SECRET`: a new, private, high-entropy value generated for this server.

Do not upload an `.env` file, the `data/` folder, or `node_modules/`. The
server creates `data/congregation_manager.db` on its first successful start;
that folder is the live database and must be included in hosting backups.

After extraction, use **Run NPM Install**, then **Restart** in cPanel. Verify
the deployment at `https://api.test.healthyharvest.co.in/api/health`.

## Publisher profile update

Deploy the updated backend before distributing the updated Flutter app. Profile
saves, elder-entered monthly reports, and marking a publisher deceased use new
congregation-scoped endpoints in `publisher_profile_routes.ts`.

Run `npm run build` before packaging this folder so `dist/server.js` and the new
profile modules are current. Keep the live `data/` directory in place. Startup
adds the deceased-status/photo columns and report audit table without deleting
publisher records or reports. Marking a publisher deceased disables linked
accounts and invalidates their existing sessions on the next API request.

To verify the backend locally, run `npm run build`, then
`node scripts/publisher-profile.test.cjs`. The tests use a separate database
under `build/profile-tests/` and never open the live database.

## Congregation report and reporting status

Restart the backend after building this update. Startup adds reporting-status
columns, monthly submission confirmations, and reminder deduplication records;
it does not replace the database. The server recalculates reporting status and
creates in-app reminders every minute while running, using the server's local
calendar. Configure the server timezone to match the congregation's calendar.

Status uses six completed months: all reported = Active, some reported =
Irregular, none reported = Inactive. A newly added publisher's initial selection
supplies pre-enrollment history until six months of actual reporting history
replace it. Submitted and accepted reports count; drafts and returned reports
do not. TMS-only students and deceased publishers are excluded from automatic
status changes.

Reports are scoped to the signed-in elder's congregation. Only its Secretary
and Coordinator may confirm JW portal submission. In-app reminders are created
once per officer per day on days 1–7, stop upon confirmation, and do not submit
anything to the JW portal. The dashboard also displays a reminder while due.

Special Pioneers and Field Missionaries are excluded from congregation report
totals and reporting-status recalculation. Pioneer hours/studies use report snapshots. AP counts also include approved
applications. Regular Pioneer counts include the current appointed roster, so older
appointment changes cannot be reconstructed from legacy data.

Verification: `npm run build`, then `node scripts/congregation-report.test.cjs`.
Tests run against an isolated database under `build/report-tests`.