This ticket can be closed. It was a combination of packages/releases that didn't played together.

I spoke too soon, after posting the above comment, the system would not allow me to log in. No calendar entries we made by anyone.

I have implemented T1988 patch, and the problem cannot be replicated.

fixed with kdepimlibs 4.13.0.32

@vanmeeuwen No, this is not a duplicate. The issue still persists with pykolab code from git-master. See Bifrost T16075 for the same issue.

Looks like this bug only happens in the old version. The most recent plugins package from Winterfell doesn't have this issue

@vanmeeuwen, The issue is fixed, but two tests fail now:

======================================================================
FAIL: test_002_check_event_conflict
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py", line 134, in maybeDeferred
    result = f(*args, **kw)
  File "/usr/lib64/python2.7/site-packages/twisted/internet/utils.py", line 191, in runWithWarningsSuppressed
    result = f(*a, **kw)
  File "/root/pykolab/tests/unit/test-011-itip.py", line 450, in test_002_check_event_conflict
    self.assertTrue(itip.check_event_conflict(event3, itip_event), "Conflict in two recurring events")
  File "/usr/lib64/python2.7/site-packages/twisted/trial/unittest.py", line 224, in failUnless
    raise self.failureException(msg)
FailTest: Conflict in two recurring events

I did a complete reinstall with kolab 16 some days ago and i am also unable to reproduce. I noticed that the ldif export from the ldap looks different now.

I've just attempted to reproduce the symptoms and it does not seem like I can. I'm going to request you wait for PyKolab version 0.8.7 in Kolab 16 and then try again.

Promoted to BifrostT9064

Try to add use_tls = true to the [ldap] section to fix the web admin.

This should be documented here, shouldn't it?
https://docs.kolab.org/upgrade-guide/kolab-16.html

This is likely a duplicate of T1988

Resolved per the aforementioned commits.

D308 isn't the proper solution to these symptoms.

The patch for the plugin package in Kolab:16 is waiting for review

I have the same syptoms on a fully updated kolab16 on centos7.
Rebooting the sever starts things going for a while until ldap is blocked again.
If it happens Roundcube login does not work and sending mails via kontact is blocked.

D308 is a little bit hacky (and may not find all conflicts), but works. And the old method wasn't perfect anyway.

In T1988#30665, @machniak wrote:

It is not infinite. It is just so extremally slow... For two weekly recurring events it does around 10 * 50 * 10 * 50 iterations. And every iteration calls getLastOccurrence(), getOccurenceEndDate(), etc. on EventCal (from kolab.calendaring). Looks like these are slow.

It is not infinite. It is just so extremally slow... For two weekly recurring events it does around 10 * 50 * 10 * 50 iterations. And every iteration calls getLastOccurrence(), getOccurenceEndDate(), etc. on EventCal (from kolab.calendaring). Looks like these are slow.

Hi machniak, the current build 16 that we are using already has the fix:
https://git.kolab.org/rP54cb493d655bb67719572acd934994161c3751af

Probably a bug fixed here: https://git.kolab.org/rP54cb493d655bb67719572acd934994161c3751af

I am seeing this also, it appears that when it happens no users can login and it usually recovers automatically after about an hour. For some reason rebooting the server does not solve.

We need more recent roundcubemail-plugins-kolab package.

These "untranslated" messages come form wallace. We need to take care the solution works also for environments where invitation policy is not used at all or is used in various other modes.

Played around with Delegation and Shared Folder to test the behaviour of both functions.

Aye, looks like so - don't see any TypeErrors with patch you proposed.

I think a date is possible here if the event is full-day recurring event. In such a case to_dt() is not used on the event last occurence date in https://git.kolab.org/diffusion/P/browse/master/wallace/module_resources.py;71df0cc7b4fc8373e6d84db8e8c01e56ca99ad25$506

Looks like my IMAP infrastructure doesn't support METADATA or ANNOTATEMORE... I think this is why we are using database_driver

Yes I am using database_driver. I don't remember why...

Do I understand correctly that you use database driver?

This problem seems to be fixed; I can no longer reproduce it.

Despite the harsh tone of the previous comment, I'm going to have to let you have an update. All gratitude is to go to the original reporter, @tobru, for allowing me to have an excuse to spend as much time and resources on this as I did ultimately have had to.

Translation was added to transifex: https://www.transifex.com/kolab/kolab/translate/#de/pykolab/93629155

This issue has escalated to another ticket known as Bifrost#T10720 for enterprise-level support.

Of course the correct version including the fix is: cyrus-imap.2.5.10

Tested and indeed there's a problem with this scenario. When handling an iTip we search for the event only in folders in personal and shared namespace. Here we have a folder in other user namespace. So, in [8] as well as in [6] the event cannot be found.

There were some related changes in git, some not packaged yet. I'll test git-master, to see if any of these issues can be still reproduced.

Groups with email address specified will not be expanded with their members.

Surely no one knows the answer to this question?

Confirmed on Fedora 23:
sudo rpm -q nss thunderbird
nss-3.27.0-1.1.fc23.x86_64
nss-3.27.0-1.1.fc23.i686
thunderbird-45.2.0-1.fc23.x86_64

Better fix submitted in D242. Waiting for approval

A test with TOTP was successful.

Hm, there seems to be some confusion between method (driver to use) and id (yubikey:<hexcode>). the plugin tried to load config['kolab_2fa_yubikey:<hexcode>'] which obvously fails. The following patch (against Winterfell) seems to fix it for me - but I didn't test HOTP or TOTP token. And already added yubikeys had to be removed and readded.

The configuration options should already make their way into the $config member of the Yubikey class. They are read in kolab_2fa::get_driver(), passed through Kolab2FA\Driver\Base::factory() all the way to Kolab2FA\Driver\Base::init() where they are merged with $this->config. It's to be investigated why the following line in Base.php doesn't work as expected:

$this->config = array_merge($this->config, $config);

Now, partially translated:

This ticket is superseded by the new Bifrost#T9079 ticket.

This ticket has been superseded by Bifrost#T9061.

fwiw:
This can be reproduced on a fully-updated ArchLinux or Fedora 24. Additional we have some reports from IOS 10 users.

The php timezone was not correct, after correcting, error resolved

Thank you for the information. We will review it and dig a little deeper into this issue (shared folder vs. delegation).

Actually RFC5546 specifies a special case of acting on behalf of an organizer. So, I suppose we could assume that having write rights to calendar is such a case. Can't we?

I didn't test yet, but then I think the described behaviour is not exactly as expected. I.e. if UserB is not the organizer I do not expect attendees (nor organizer) to be informed. We should not send cancellation emails with UserB's as a sender. Or maybe we should? That's problematic.

@machniak I am not using identities or delegation, it just a simple shared folder.

@Robert_Selk are you using delegation feature or simple ACL modification? Or in other words, does UserB have identities with UserA's addresses? I'm asking just to be sure I test the same scenario.