wallace dies after trying to SELECT mailbox with lr access rights
Open, NormalPublic


While investigating why some emails never gets out of wallace spool I found that some emails make wallace crash with the following trace back:

2018-02-21 10:05:39,912 pykolab.wallace ERROR Unknown error occurred; readonly('Other Users/dddd/Calendar is not writable',)
2018-02-21 10:05:39,914 pykolab.wallace ERROR Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/wallace/", line 118, in execute
    return modules[name]['function'](*args, **kw)
  File "/usr/lib/python2.7/site-packages/wallace/", line 367, in execute
    done = processor_func(itip_event, policy, recipient_email, sender_email, receiving_user)
  File "/usr/lib/python2.7/site-packages/wallace/", line 1377, in propagate_changes_to_attendees_accounts
    (attendee_object, master_object) = find_existing_object(object.uid, object.type, recurrence_id, attendee_user, True)  # does IMAP authenticate
  File "/usr/lib/python2.7/site-packages/wallace/", line 847, in find_existing_object
  File "/usr/lib64/python2.7/", line 671, in select
    raise self.readonly('%s is not writable' % mailbox)
readonly: Other Users/dddd/Calendar is not writable

Turns out that the calendar in question is shared for some users with lr type of acls. This makes IMAP SELECT command to return [READ-ONLY] and raises the exception. After I changed acls to lrs the messages were digested by wallace and left the queue.
I think this read-only exception should be caught by pykolab and should not make wallace die. So every should be in try ... except pykolab.


Ticket Type

Event Timeline

vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:12 AM
pasik added a subscriber: pasik.May 23 2019, 2:25 PM