Move imip data into a separate database table
@steven-mpawulo is already working on this.
Since Jul 20, 2026.
- Dominant language
- JavaScript
- Stars
- 1k
- Forks
- 348
- Avg merge
- 12h 28m
- Merged PRs (30d)
- 91
Description
Is your feature request related to a problem? Please describe.
Is your feature request related to a problem? Please describe.
The mail_messages table contains three iMIP-related columns (imip_message, imip_processed, imip_error) in every row. Code analysis shows:
- These columns track calendar invite processing status
- Only messages with calendar attachments have imip_message = TRUE
- imip_message is not used by frontend code (verified via grep search)
- Only IMipMessageJob background process queries these columns
For messages without calendar invites, these columns store NULL/FALSE values but still occupy table space.
Describe the solution you'd like
Create a separate table for iMIP tracking, where row presence indicates a calendar invite:
CREATE TABLE mail_messages_imip (
message_id BIGINT PRIMARY KEY,
error BOOLEAN DEFAULT FALSE,
processed_at INTEGER,
FOREIGN KEY (message_id) REFERENCES mail_messages(id) ON DELETE CASCADE,
INDEX idx_unprocessed (error, processed_at)
);
Changes:
- Row existence indicates message is a calendar invite (replaces imip_message column)
- error tracks processing failures (replaces imip_error)
- processed_at tracks completion; NULL = unprocessed (replaces imip_processed)
Migration:
INSERT INTO mail_messages_imip (message_id, error, processed_at)
SELECT id, imip_error, CASE WHEN imip_processed THEN UNIX_TIMESTAMP() ELSE NULL END
FROM mail_messages
WHERE imip_message = TRUE;
ALTER TABLE mail_messages
DROP COLUMN imip_message,
DROP COLUMN imip_processed,
DROP COLUMN imip_error;
Code updates needed:
- IMipMessageJob: Query new table instead of main table
- PreviewEnhancer: Insert to new table when calendar attachment detected
- Message entity: Remove iMIP column accessors
Describe alternatives you've considered
Describe alternatives you've considered
- Keep current schema - simpler, no migration needed
- Move to JSON column - harder to query efficiently
Sparse table approach follows standard practice for low-cardinality optional data.
Additional context
Additional context
Files to modify:
- lib/Db/ImipData.php (new entity + mapper)
- lib/BackgroundJob/IMipMessageJob.php
- lib/IMAP/PreviewEnhancer.php
- lib/Db/Message.php
- Migration file
AI-assisted: Claude Code (Claude Haiku 4.5)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.