Here's the plain-language summary of where things actually stand, cutting through everything we've tried:
Issue #1 — Timezone display bug: FIXED ✅
Ticket times were showing 5.5 hours earlier than actual (DB stores IST time directly, but osTicket assumed it was UTC and wrongly subtracted the offset). You hardcoded the fix in class.timezone.php and class.format.php. Confirmed working on live tickets.
Issue #2 — Outbound mail (Postfix): FIXED ✅
Emails were failing to send ("Unable to email via Sendmail"). Turned out to be a Postfix permissions problem, now resolved — mail is delivering successfully.
Issue #3 — Ticket locking: STILL UNRESOLVED ❌ — this is your actual current issue
Agents can't reply to or close tickets. They get: "This action requires a lock. Please try again!"
We found and fixed one real bug along the way (expired locks not clearing their reference on the ticket — fixed with a cron job), but that wasn't the main cause. The clearest evidence: on ticket #385092, the lock in the database was completely valid and not expired, yet the error still happened. That means something else is broken — most likely, the lock "code" your browser submits doesn't match the code currently valid in the database, possibly because a new lock gets silently issued in the background while the page sits open, and the page never picks up the new code.
We haven't found the root cause yet. We were in the middle of trying to inspect the actual network request (via browser DevTools → Network tab → Payload) to see exactly what code your browser sends versus what the DB expects, but that got paused when you asked to draft the forum post instead.
So, in one sentence: your open issue is that ticket locking is broken — agents can't reply/close tickets — and the cause isn't confirmed yet.
Want to go back to the DevTools Network tab check to pin it down, or wait for a forum response first?
