Move imip data into a separate database table

[ChristophWurst]

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

1. Keep current schema - simpler, no migration needed
2. 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)

[ChristophWurst]

Is is likely a micro optimization as the drop of the three columns only gives a few bytes of saving per row. For 100 Million rows this could be ~381.4 MB. It's not a lot in relative terms.

[ChristophWurst]

Assigning myself until we know if this is desired.