Not a problem in Kolab 16.

Correcting the priority from 60/40 to Normal

Correcting the priority from 60/40 to Normal

Correcting the priority from 60/40 to Normal

No more support for Debian Wheezy.

I'm closing this because we don't support Debian Wheezy any longer.

Fixed in dfacbe01bca [master] and acc49b51fff [roundcubemail-plugins-kolab-3.2].

See also T2208.

This is a duplicate of T1847.

@vanmeeuwen, So we have a case with no delegation, but with a shared folder where user (with write rights) deletes an event. Considering my comment here https://git.kolab.org/T1357#27566 and the next one, what would you propose? Note that we first have to solve this independently from what wallace does, i.e. define what iTip messages are sent and when, should we use SENT-BY field, etc. Then how wallace would handle that is another story.

Any news for this issue?

Promoted to BifrostT9064

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.

got new Version here

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

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

Now, partially translated:

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.

Tested it with Rouundcube Plugins 3.2.15-4.1.el6.kolab_14.

would you like to change the status of this to some other Status than open? As far as I see now a kolab package for 2.5.9 exists right now.

According to Florian Eder, this has been tested and is working.

I will close this for now - Please feel free to reopen if there are still issues related to this.

Is this still an issue, or did the increase of filehandles configuration resolve the issue?

Just to confirm: It was a faulty PHP-Mailer-Version that caused this issue.

root@debian:~# dpkg -l apache*
Desired=Unknown/Install/Remove/Purge/Hold

+++-======================-================-================-=================================================
ii apache2 2.4.10-1.1 amd64 Apache HTTP Server
un apache2-api-20120211 <none> (no description available)
ii apache2-bin 2.4.10-1.1 amd64 Apache HTTP Server (binary files and modules)
ii apache2-data 2.4.10-1.1 all Apache HTTP Server (common files)
un apache2-doc <none> (no description available)
un apache2-mpm-event <none> (no description available)
un apache2-mpm-itk <none> (no description available)
ii apache2-mpm-prefork 2.4.10-1.1 amd64 transitional prefork MPM package for apache2
un apache2-mpm-worker <none> (no description available)
un apache2-suexec-custom <none> (no description available)
un apache2-suexec-pristin <none> (no description available)
un apache2-utils <none> (no description available)
un apache2.2-bin <none> (no description available)
ii apache2.2-common 2.4.10-1.1 amd64 Transitional package for apache2

What is the web server software that is installed (prior to setup-kolab)?

This is also the case for the wheezy installation

The installation is left in a non working state and with this truncated /etc/imapd.conf (the same every time):

=?iso-8859-15?Q?Stellenausschreibung-=C4nderung:_16-2509-075, IT@M, A10/E9_TV=F6D?=

This is not a valid header value according to RFC2047. Encoded-word can't contain spaces. What client created this?

"the implementation" here is cyrus.

Since I'm not sure if roundcubemail does that already cyrus may not be the source of the umlauts problem.

Can you please elaborated why REJECT does not make sense?
There is a use when reservation requests to meeting room should be allowed to particular users only. VIP car is allowed to certain users to be reserved is yet another case I can think of.
Please share all the logic behind resource reservation then.

As discussed with Jeroen REJECT does not make much sense for resources. So, I don't see anything in the code that would need to be fixed now. Consider updating documentation to be more precise.

Again, the resources module is a different module from the invitation policy. I read this ticket as concerning the invitation policy. I'm not sure how the resources module got in to the mix.

As I understand setting kolabinvitationpolisy: ALL_REJECT for resources does not work as for users, i.e. does not respond with Declined status.

The resources module is a different one from the invitation policy module. This ticket concerns the invitation policy module.

In addition it is not clear what ALL_MANUAL policy means for resources. There is nobody behind the resource, so nobody can manually react to the reservation request. Even more, resource is calendar, so it has no mail type folder to deliver request.

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?

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.

Reproduced inhouse

/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

I tested on a system where I copied the sound files to the correct location some earlier, and that's why the test seamed to work but unfortunately this is not solved. The sound files are still not available at the correct path after package new/first installation.

A better diff for fixing the problem.

@@ -492,8 +497,11 @@ def expunge_resource_calendar(mailbox):
                     # skip if recurring forever
                     continue