Problem Channel::Filter::IdentifySessionUser (NameError)

Infos:

  • Used Zammad version: 6.5.2-176194277.bc4a754e.bullseye
  • Used Zammad installation type: package (Debian package)
  • Operating system: Debian 12 Bookworm

Expected behavior:

  • Emails should be fetched from Microsoft365 IMAP account and processed normally
  • Channel should process incoming emails without errors
    Hi All,

Actual behavior:

  • Emails are fetched successfully from outlook.office365.com but fail to process
  • Error: uninitialized constant Channel::Filter::IdentifySessionUser (NameError)
  • Error occurs at: app/models/channel/email_parser.rb:172:in 'block in _process'
  • Failed emails accumulate in FailedEmail table

Steps to reproduce the behavior:

  1. Fresh Debian 12 installation
  2. Install Zammad 6.5.2 via package
  3. Restore backup from Zammad
  4. Configure Microsoft365 IMAP channel with XOAUTH2
  5. Emails are fetched but processing fails with IdentifySessionUser error

Additional context:

  • Migration from Debian 10 to Debian 12
  • Backup restore was successful
  • Database and files restored correctly
  • Other Zammad functions work normally
  • Only email processing fails with this specific error
  • Channel configuration shows no ‘identify_session_user’ filter in database

Appreciate your help.

How exactly did you backup and restore? With all files or just attachments…? This information is quite crucial. Also we do not know which steps you have taken.

I mean we can assume that you’ve followed the documentation, but you might have slipped a step.
I couldn’t find the mentioned definition on my current 6.5.2 installation, so I’m gonna guess that your database does not match your filesystem.

This is what you should see in a rails console (nothing more, nothing less):

[2] pry(main)> Setting.where(area: 'Postmaster::PreFilter').pluck(:name)
=> ["0955_postmaster_filter_bounce_delivery_temporary_failed",
 "1000_postmaster_filter_database_check",
 "0005_postmaster_filter_trusted",
 "0006_postmaster_filter_auto_response_check",
 "0007_postmaster_filter_follow_up_check",
 "0008_postmaster_filter_follow_up_merged",
 "0009_postmaster_filter_follow_up_assignment",
 "0011_postmaster_sender_based_on_reply_to",
 "0018_postmaster_import_archive",
 "0012_postmaster_filter_sender_is_system_address",
 "0014_postmaster_filter_own_notification_loop_detection",
 "0015_postmaster_filter_identify_sender",
 "0030_postmaster_filter_out_of_office_check",
 "0200_postmaster_filter_follow_up_possible_check",
 "0900_postmaster_filter_bounce_follow_up_check",
 "0950_postmaster_filter_bounce_delivery_permanent_failed",
 "0016_postmaster_filter_secure_mailing",
 "5000_postmaster_filter_icinga",
 "5100_postmaster_filter_nagios",
 "5300_postmaster_filter_monit",
 "5400_postmaster_filter_service_now_check",
 "5400_postmaster_filter_jira_check",
 "5500_postmaster_internal_article_check"]

To double tab this, run /opt/zammad/contrib/packager.io/postinstall.sh which will do everything that happens during an update. Just be be sure there’s not more luring at you.

Hi MrGeneration,

Backup and Restore Process:

  • Backup source: Debian 10, Zammad 6.5.2-176433097.bc4a754e.bullseye
  • Target: Fresh Debian 12, Zammad 6.5.2-176194277.bc4a754e.bullseye
  • Backup created with: /opt/zammad/contrib/backup/zammad_backup.sh
  • Restored with: /opt/zammad/contrib/backup/zammad_restore.sh
  • Backup files: Both database (zammad_db.psql.gz) and files (zammad_files.tar.gz) were restored

Current Issue:
You are correct - my database does not match the filesystem.

My PostmasterFilter list shows obsolete filters:

  • “6500_postmaster_filter_identify_sender” (should be “0015_…”)
  • “6005_postmaster_filter_identify_group” (shouldn’t exist)
  • “6105_postmaster_filter_sender_is_system_address” (should be “0012_…”)
  • “5200_postmaster_filter_check_mk” (shouldn’t exist)

I ran /opt/zammad/contrib/packager.io/postinstall.sh as you suggested, but it did not fix the filter list.

Question:
How can I safely reset/recreate the PostmasterFilter settings to match a clean 6.5.2 installation without losing my tickets and data?

Thank you!

[1] pry(main)> Setting.where(area: 'Postmaster::PreFilter').pluck(:name)
=> ["0007_postmaster_filter_follow_up_check",
 "5100_postmaster_filter_nagios",
 "0008_postmaster_filter_follow_up_merged",
 "5300_postmaster_filter_monit",
 "0006_postmaster_filter_auto_response_check",
 "0011_postmaster_sender_based_on_reply_to",
 "0018_postmaster_import_archive",
 "0030_postmaster_filter_out_of_office_check",
 "0200_postmaster_filter_follow_up_possible_check",
 "1000_postmaster_filter_database_check",
 "5000_postmaster_filter_icinga",
 "0000_postmaster_filter_trusted",
 "0950_postmaster_filter_bounce_delivery_permanent_failed",
 "0955_postmaster_filter_bounce_delivery_temporary_failed",
 "0009_postmaster_filter_follow_up_assignment",
 "5400_postmaster_filter_jira_check",
 "0014_postmaster_filter_own_notification_loop_detection",
 "0900_postmaster_filter_bounce_follow_up_check",
 "5400_postmaster_filter_service_now_check",
 "5500_postmaster_internal_article_check",
 "5200_postmaster_filter_check_mk",
 "6500_postmaster_filter_identify_sender",
 "6005_postmaster_filter_identify_group",
 "6105_postmaster_filter_sender_is_system_address",
 "0001_postmaster_filter_secure_mailing"]

What does zammad run rake db:migrate --trace return? It should have pending migrations… unless you have custom addons that hook into mail processing that you forgot to install?

No addon.

root@debian-12-server:/home/technique# zammad run rake db:migrate --trace
WARNING: Nokogiri was built against libxml version 2.9.10, but has dynamically loaded 2.9.14
WARNING: Nokogiri was built against libxslt version 1.1.34, but has dynamically loaded 1.1.35
** Invoke db:migrate (first_time)
** Invoke db:load_config (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:load_config
** Execute db:migrate
** Invoke db:_dump (first_time)
** Execute db:_dump
root@debian-12-server:/home/technique#