Yes, ACT_MANUAL is an alias for ALL_MANUAL in invitationpolicy module, but as I've said resources module supports only three policies. We should probably add support for ALL_* aliases, but adding support for all policies supported by invitationpolicy module would not be just a simple fix. That's why I'd like Architecture & Design to take a look at this.

Update: user invitation policy handling works, at least I can get invitation declined. It is declined either setting ALL_REJECT or ACT_REJECT.

As for the resources, in the code I see this module support only three policies: ACT_MANUAL, ACT_ACCEPT and ACT_ACCEPT_AND_NOTIFY

Works for me on KE14 (pykolab 0.7.28). What policy do you have in kolab.conf?

With pykolab 0.7.28 we discover the same issue.

Had the same issue, workaround worked.

In T1404#22635, @machniak wrote:

Could you try if dropping policy_result table in kolab database fixes the issue. The table will be re-created automatically.

Just debugged the same stuff with pykolab-0.8.3-3.1.el7.kolab_16.noarch, same behaviour.

I'm getting the same error message with current Winterfell, but it does not stop on dropping the table. On the other Hand I have no mail submit issues.
Dirsrv logs this errors:
[10/Aug/2016:19:39:09 +0200] connection - conn=3666 fd=64 Attempt to release connection that is not acquired
[10/Aug/2016:19:42:43 +0200] connection - conn=3682 fd=65 Attempt to release connection that is not acquired
[10/Aug/2016:19:44:09 +0200] connection - conn=0 fd=0 Attempt to release connection that is not acquired
[

I was able to fix the issue on moving/resizing the event, but I wasn't able to reproduce the issue on event delete. I'm closing the ticket now. Please, reopen if the issue still exist after aplying my change.

I restored the non-working kolab_smtp_access_policy, confirmed that the issue returned, dropped the policy_result table, et voilà! The issue is fixed. Thanks a lot for the quick help!

Ok, more testing. I see now where the problem is. I think I misunderstood the problem description as there was no word "delegation" ;)

Could you try if dropping policy_result table in kolab database fixes the issue. The table will be re-created automatically.

I'm not able to reproduce the notification issue. I.e. when I delete or move or edit such an event iTip notifications are not being send. Which would mean that the only problem really is misleading wording of the warning text.

A failure of a load-balancer under the product name of F5 may in fact be creating long-lasting connections as well, as it tends to send a SYN, await the SYN, ACK, but never RST or ACK,FIN.

Hello,
The development phase is when the costs to find bugs and improve documentation are lower than at production phase.
We posted the installation report to help kolabsystems to improve its documentation.

Fixed display issue.

There's no technical provision that prevents us from allowing users to create multiple groups by the same name, provided that the data-to-presentation application logic uses keys that uniquely tie an entry to a (specific instance of a) group. Both SQL (primary index auto-increment) and Kolab (xml/uuid) provide these artifacts.

Some of the behavior that seems to be requested (albeit not explicitly) leans toward workflow management more so than it is squarly within the realm of simple task management.

Please note that, IIRC, the freebusy service renders Free/Busy information with a certain timeslot as well -- if any event overlaps either of the lower or upper boundaries the entire slot is considered busy.

I would suggest to consider sending out the notifications of the changes as user2, in that this is rendered quite dysfunctional practically, should no notifications be sent out at all.

I was talking about default behavior of sql addressbook (which you do not use), just to show possible (counter) solution.

The first issue was fixed in ab433d7428d6 (not packaged yet). The other is pykolab localization issue and is already part of T1358.

But it is not shown in the addressbook as "My Group 2". Only "My Group" is shown but with the Content of "My Group 2".

The default sql addressbook in Roundcube has functionality that makes sure new group (or renamed group) name is always unique instead of throwing an error. E.g. If you have group "My Group" and you try to create another with the same name, Roundcube will just create group with name "My Group 2".

Please note, from: https://docs.kolab.org/installation-guide/winterfell/index.html

Relevant OTRS issues:
1100085

While I'm investigating the missing groups issue.... I couldn't reproduce the first described issue. I think this may depend on ldap configuration (and vlv configuration). Please, provide your ldap_public config and progide ldap_debug log.

Reproduced inhouse

Fixed in Transifex and updated in git for release-1.1 branch.

Fixed in git and Transifex.

So, we have two issues here:

Fixed in git and Transifex.

As far as we know until now this is the same with shared folders where the KolabTargetFolder gets edited.

/var/log/guam/console.log:2016-08-01 09:24:47.545 [error] <0.28149.319> CRASH REPORT Process <0.28149.319> with 0 neighbours exited with reason: no match of right hand value {error,emfile} in kolab_guam_session:post_accept_bookkeeping/4 line 143 in gen_server:terminate/7 line 826

There is an Option called "subscribe-user" https://docs.kolab.org/administrator-guide/using-the-kolab-command-line.html#subscribe-user
which does not seem to exist.

Tested and it seems to be working.

Tested and it seems to be working.

Since we had to remove the e-mail to get the sync to work again I had to recreate it.

Thanks for the report; this will go into packaging. You are also welcome to "roll up your sleeves and help out" if you wish to do so by going here: