Skip to content

mail_room: Allow configuration of delete_after_delivery parameter

Stan Hu requested to merge sh-mailroom-delete-after-delivery-config into master

What does this MR do?

In IMAP, delete_after_delivery only marks the message as deleted, but a separate expunge_deleted step is needed to permanently remove the message.

In Microsoft Graph, delete_after_delivery soft-deletes the messages, but the message is automatically expunged after a retention period, typically 14 days. An admin can manually expunge deleted messages via the command-line.

delete_after_delivery has been set to true by default since gitlab-org/gitlab@712d1768 since it wasn't necessary to configure this for IMAP, but it is necessary for Microsoft Graph since this auto-expunge behavior may not be desired. We now make this option configurable with true by default.

Related issues

Relates to gitlab-org/gitlab#386770 (closed)

Testing

I used this config:

  --set global.appConfig.incomingEmail.address=stanhu+%{key}@redacted.onmicrosoft.com \
  --set global.appConfig.incomingEmail.enabled=true \
  --set global.appConfig.incomingEmail.user=stanhu@redacted.onmicrosoft.com \
  --set global.appConfig.incomingEmail.inboxMethod=microsoft_graph \
  --set global.appConfig.incomingEmail.tenantId="REDACTED" \
  --set global.appConfig.incomingEmail.clientId="REDACTED" \
  --set global.appConfig.incomingEmail.clientSecret.secret=incoming-email-client-secret \
  --set global.appConfig.incomingEmail.deleteAfterDelivery=false

With the last line present, I confirmed delete_after_delivery was set to false in the mail_room.yml, and a new e-mail remained in the inbox:

image

Without the last line, I confirmed delete_after_delivery was set to true in the mail_room.yml. A new e-mail end up in the recoverable Deleted box:

image

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

  • Merge Request Title and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • Documentation created/updated
  • Tests added
  • Integration tests added to GitLab QA
  • Equivalent MR/issue for omnibus-gitlab opened
  • Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.
Edited by Stan Hu

Merge request reports