Mohith 218 hr tables

[MohithS04]

Database Objects Created

One ENUM type: internal_app_status_type with four values
Three tables:

internal_applications — live inbox, with all PDF fields plus auto-managed timestamps
internal_app_rejections — audit pile, rejection_id UUID PK, full applicant snapshot plus rejection metadata
internal_team — active members, profile fields plus joined_at, is_active, deactivated_at, internal_role

Indexes on status, reviewer_cognito_id, created_at for HR queue queries

1. Trigger Logic Implemented

updated_at_handler extended: two new ELSIF branches added for internal_applications and internal_team, dispatched by TG_TABLE_NAME
handle_internal_application created: new function with two mutually exclusive branches (approval, rejection)
Three triggers attached:

trg_internal_app_updated_at — BEFORE UPDATE on internal_applications for timestamps
trg_internal_team_updated_at — BEFORE UPDATE on internal_team for timestamps
trg_handle_internal_application — AFTER UPDATE on internal_applications for state-machine routing

2. Key Trigger Mechanics Explained

BEFORE UPDATE modifies the row before it's saved (used for timestamp auto-stamping)
AFTER UPDATE runs after the row is committed (used for the migration to other tables and deleting the source)
TG_TABLE_NAME is the magic variable that lets one function serve multiple tables
IS DISTINCT FROM is the null-safe equality check, used everywhere change detection matters
Transition guards (NEW.status = 'X' AND OLD.status != 'X') prevent duplicate firing on already-terminal rows
COALESCE on rejection_reason prevents NOT NULL violations if HR forgets to set the reason
RETURN NEW is required syntactically even for AFTER triggers where the return value is ignored

[PallaviChitrada10]

The volunteer application SQL file is for the "Become a Volunteer" feature. The HR table, "Join the team", would have a similar structure of beneficiaries joining the team.

[MohithS04]

Hi Pallavi, two quick questions before I finish the HR migration:

1. I noticed the updated ddl_volunteer_applications.sql already has an internal_applications branch in updated_at_handler with four separate S3-key timestamp columns (resume, EAD, i20, government_id). I'd been planning a single combined timestamp. Should I match the four-column pattern that's already in the file, or is that section a work-in-progress that's still up for change?
2. You mentioned the HR / "Join the Team" feature should follow the structure of beneficiaries joining the team. Can you point me to the beneficiary tables (file path or table names)? That sounds like a closer reference than the volunteer flow I've been copying.
   I have the three tables, two functions, and three triggers drafted. Once I have answers to these two, I can finalize and open the PR.

[MohithS04]

Updated handle_internal_applications, In this SQL file the code describes the Approved Path and Rejected Path. After that It has 3 triggers and enabling them.