[Bug]: Delete Sent Email

[cbyrdmo]

Which version are you running?

4.2.12

How is it installed?

Git clone on Windows (XAMPP or similar)

What page or screen were you on?

Messages

What went wrong?

Tried to delete sent message. It does not delete

What steps lead to it?

Went to Sent messages, highlighted message, clicked delete, confirm message pops up, move message to trash,
Message does not delete.

Messages do delete from the Inbox

Screenshot (optional)

No response

What device / browser?

No response

[ejosterberg]

Found the cause: the delete action only ever knew how to remove a message from the recipient's side. A message you sent has no recipient row keyed to you, so a Sent-view delete matched zero rows and silently did nothing -- Inbox deletes worked because there IS a row on that side.

Sent messages can now be deleted independently, with their own tracking so it never affects what the recipient sees (or vice versa).

Fixed in v4.2.13, live on training and Bloomington now, and in the public repo. Pull, refresh, and give it another try -- please reopen if it's still not right.

[cbyrdmo]

Testing the delete function and that is working correctly. I do show system messages that are in my sent box are undeletable. I am not sure if this is a feature or bug..

[ejosterberg]

Good catch to flag rather than assume -- checked the code, and it's a feature, by design (predates this fix, from back in June): the Sent view merges two different things into one list. Real internal messages (the ones you compose and send to other users) are clickable and now delete correctly, per the fix above. The other rows -- SMS/email/Slack sends routed through the messaging system -- are a send-and-forget log, not a message with a thread to manage, so they're deliberately non-clickable with no delete option; that's what you're seeing as "undeletable." They show a delivery-status badge (delivered/failed/pending) instead.

If having a way to clear out old entries from that log would be useful to you, happy to look at adding one -- just didn't want to build something you didn't actually need. Let me know either way.

[cbyrdmo]

It may be a good thing to be able to delete those. I imagine they could grow over time. Once we close an event, we hold the data for a couple months (unless there is a major incident) and then we purge the data. Our cad usage is not like a typical dept that runs calls year round. We are more event/disaster driven.

[rjonesbsink]

On the "I imagine they could grow over time" question — some numbers from a real
install, since it's easy to measure and it turned out larger than I expected.

Growth, measured

This box has been running about two weeks. messages, the table behind the
non-clickable rows in Sent (direction='outbound', channel <> 'local_chat'):

outbound rows shown in Sent : 853
date range                  : 2026-07-27 .. 2026-08-09  (14 days)
on-disk size                : 1.6 MB

That's roughly 60 rows a day on an install with no real call volume — a handful of
test incidents and some automation. Extrapolated it's ~22,000 rows and ~40 MB a year,
and a live agency would be well above that.

The composition is the part I'd flag

slack     293
telegram  291
push      276
local_chat 21
smtp        5
dmr         1

Nearly all of it is automated notification fan-out, not messages a person composed.
One alert going to three destinations writes three rows, each appearing in somebody's
Sent view.

Worth caveating: this install runs weather alerts and web push, so my mix is
automation-heavy by construction. An install using the messaging bridges differently
would see a different split. But the shape — outbound log dominated by machine traffic
— seems likely to hold anywhere the bridges are enabled, and it argues that per-row
delete buttons would be the wrong ergonomics for the bulk of it. Nobody is going to
tick 22,000 checkboxes.

There may already be a pattern for this in the tree

messages has no soft-delete column (id, channel, direction, msg_type, sender, recipient, subject, body, priority, status, error, payload, delivered_at, created_at),
so a per-row delete would need a schema change, whereas an age-based purge wouldn't.

And Phase 133 already built almost exactly this for the audit log:

• inc/audit-retention.php — the policy
• tools/audit_log_purge_tick.php — the scheduled tick
• audit_log_purges — one row per run: cutoff_date, rows_purged,
  archive_filename, archive_sha256, triggered_by, status

with three principles stated in that file's header: off by default, archive before
delete, no hard-enforced floor. Its own comment says it was deliberately mirrored on
inc/backup_schedule.php because it's the same problem shape. An outbound message log
looks like a third instance of that shape rather than something new.

There are already six *_days retention settings on this install
(zello_retention_days, net_checkin_retention_days, chat_retention_days,
audit_log_retention_days, log_days, tile_cache_days), so a seventh would sit in
familiar company rather than introducing a concept.

Why the archive step may matter here specifically

@cbyrdmo's description — hold the data a couple of months after an event closes, then
purge — is precisely archive-before-delete rather than plain deletion. For an
event-driven agency the outbound log is a record of who was notified and when, which
is the sort of thing that gets asked about after an incident. Dropping the rows
outright and having them gone is a different proposition from moving them to a gzip on
disk.

Entirely your call on whether any of this is worth building; I'm just flagging that the
machinery and the design decisions may already exist and could be pointed at a second
table. Happy to test on 4.2.14 / Windows / IIS, and I have a populated messages table
to test a purge against.

[ejosterberg]

Appreciate the real numbers, @rjonesbsink — 853 rows / 1.6MB in 14 days on one install is a useful data point, and event-driven usage like Chris's (hold for a couple months, then purge) makes "let it grow forever" a worse default than it'd be for a department running calls year-round. Agreed this is worth doing. Leaving open as a feature request — Eric's call on priority against everything else in the queue.

[ejosterberg]

Built the retention follow-on for the outbound message log (the SMS/e-mail/Slack delivery rows in Sent that don't otherwise go away). Settings → Pending Messages → Message Log Retention — off by default, set a number of days and a daily sweep purges anything older. Internal chat history is never touched by this, only the delivery-log rows. Live on training and Bloomington.

[ejosterberg]

@cbyrdmo — can you confirm and close this one if it's resolved on your end?

[cbyrdmo]

I set it to 1 days and I get this warning

along with a File and Code Health 1 Critical

I am not sure how to trigger the daily sweep to see if it deletes anything.

If I set the purge rows older than (days) to 0 the critical error goes away

[ejosterberg]

That critical is real, not a false alarm -- and it's a gap on my end, not yours. The purge job itself is fine, but I never shipped the systemd timer setup for it (or the docs for it), so the moment you turn the setting on, the job is stuck at "never run" and the health check correctly flags that.

I've added it to docs/MAINTENANCE-RUNBOOK.md now. Until that release ships, here's what to add on your server (adjust the two paths if your install lives somewhere other than /var/www/newui):

# /etc/systemd/system/ticketscad-message-log-purge.service
[Unit]
Description=TicketsCAD message-log retention purge
After=network.target mariadb.service mysql.service

[Service]
Type=oneshot
User=www-data
Group=www-data
WorkingDirectory=/var/www/newui
ExecStart=/usr/bin/php /var/www/newui/tools/message_log_purge_tick.php

# /etc/systemd/system/ticketscad-message-log-purge.timer
[Unit]
Description=Run the TicketsCAD message-log retention purge daily

[Timer]
OnBootSec=10min
OnUnitActiveSec=1d
AccuracySec=1h
Persistent=true
Unit=ticketscad-message-log-purge.service

[Install]
WantedBy=timers.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable --now ticketscad-message-log-purge.timer

That'll clear the critical the next time the health check runs. If you'd rather not deal with it right now, setting the retention days back to 0 (disabled) is a safe fallback -- no critical, no purge, same as it's been all along.

[ejosterberg]

One more thing worth recording here for anyone on Windows: the systemd timer above only covers Linux. Checked, and the Windows side had the identical gap -- tools/run-scheduled-jobs.bat (the script a Windows/IIS install registers via Task Scheduler for its background jobs) had never been updated to actually invoke this purge, or the audit-log purge either, even though both were declared in the job registry. Same failure mode as the Linux gap above: the job shows up in Settings but is stuck at "never run" until the scheduler is wired to call it.

Fixed in the dev tree -- both purges are now included in the same Task Scheduler entry the install guide already has you create (docs/INSTALL-WINDOWS-IIS.md section 5). If you're on Windows and already following that guide, no extra registration needed once this ships; the existing "TicketsCAD Background Jobs" task picks up both new lines automatically on update.