Looking at the email source the for the invitation there's this part (IDs changed, so it's not proper link to test with):
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 12 2020
Sep 14 2020
Sep 3 2020
I see Debian 10 has been added in OBS, is anyone working on adding CentOS 8?
Aug 25 2020
I didn't know that wallace created generate calender placeholder. Do they have an update for this? Hoping that they fix it as soon as possible.
Aug 12 2020
Any thoughts about how to fix this issue?
Jul 6 2020
Yes I agree a 1000% (three zeros!)
I taught about it a while ago, but was very busy,
Jul 4 2020
Hello gpunk,
May 21 2020
Changing to hight, since it is a non working advertised feature -- hence a blocking problem .
May 3 2020
Jan 9 2020
Patch seems to work. I haven't seen this issue after applying the patch. Thanks a lot!
Dec 3 2019
I've updated my kolab installation from Debian 9 to 10. All in all nothing major. Highlights:
Nov 25 2019
If you feel courageous enough, I would say it's ready for field testing. Should you encounter any remaining rough edges, please report them so they can be ironed out.
Nov 23 2019
I've seen in OBS that we now build packages for Debian 10.
What's your opinion: Is it probably ready to upgrade my instance?
The only package failing to build is chwala - where I could possiby use the old package...
Nov 8 2019
@machniak Thanks a lot! I'll try the patch. This .ics arrived from Microsoft Exchange Server 2010 (based on the PRODID field in .ics).
Fixed.
Further investigation shows that actually Kolab format has CutypeRoom and CutypeUnknown defined. So, we can add these to the map, but still we should probably silently ignore unsupported values.
According to RFC5545 ROOM, UNKNOWN, X-* are valid values. Those aren't supported by Kolab, but we definitely should not throw exceptions on these. I wouldn't touch the map variable. Probably better to handle these in set_cutype().
Nov 6 2019
Oct 4 2019
I believe this was already fixed back in June with https://obs.kolabsys.com/package/rdiff/Kolab:Winterfell/kolab?linkrev=base&rev=37.
I'm working on providing Debian 10 packages for Kolab 16.
Oct 2 2019
According to https://obs.kolabsys.com/project/show/Kolab:Winterfell
RHEL_8 and Debian_10.0 have been added to Winterfell.
So my most pressing wishes have been granted :-)
Sep 29 2019
Fixed in 3841f63fbd42 [roundcubemail master] and eee719e6d2f87 [roundcubemail-plugins-kolab master].
This issue is a bug in Roundcube sql cache, so is reproducible with $config['imap_cache'] = 'db' and of course only when using MySQL engine. No issue if it's set to memcache, redis or disabled.
Jul 25 2019
Jul 5 2019
Jun 2 2019
Mar 27 2019
This ticket is both old, as well as appears to be out-dated, in the sense that further updates to guam have been made available that also, supposedly, work, and was originally reported by an employee for another one of our then-employees to address.
Mar 22 2019
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Correcting the priority from 60/40 to Normal
Jan 16 2019
Dec 10 2018
This should be documented here, shouldn't it?
https://docs.kolab.org/upgrade-guide/kolab-16.html
Aug 8 2018
Jul 3 2018
In T2289#37694, @vanmeeuwen wrote:The immediate workaround is to set smtp-wallace_destination_recipient_limit = 1 in /etc/postfix/main.cf.
Jun 9 2018
Duplicate of T4049.
Jun 7 2018
Jun 4 2018
May 2 2018
No more support for Debian Wheezy.
Mar 5 2018
Patch applied in 239783c3dd576.
Feb 1 2018
Dec 5 2017
Aug 31 2017
Hello,
i reported the problem by the beginning of 2017 using the mailing list.
Since it hasn't been resolved, i disabled guam by changing the cyrus config.
This was with version 0.9.2-1.
Now, today i gave it a try and installed version 0.9.2-3. (Running on debian jessie).
Thunderbird can get the mails in the inbox, but when it starts to index the folders, thunderbird hangs.
On the server i strace the guam process and see, that there are unjoined threads and they never join.
Perhaps a hint, since erlang is based on threads.
As for now, i disabled guam again.
Aug 3 2017
Jul 22 2017
Jul 21 2017
Hi. Any chance to get some feedback on this? If the change needs to be adjusted, or a related ticket needs to be created, i just need to know it.
Jul 5 2017
Add changes in wallace for correct handling too
Jul 3 2017
The immediate workaround is to set smtp-wallace_destination_recipient_limit = 1 in /etc/postfix/main.cf.
Jun 30 2017
@vanmeeuwen, what's your take on this?
Hmm, the user who has been reporting this issue uses some mobile email client in addition to the kolab roundcubemail, so it *might* be related to mobile client, but I'm not sure really..
Any thoughts/plans about fixing this issue? Users hit this issue very often, because currently kolab auto-updates only the *first* recipient calendar..
Jun 29 2017
Still can't find the way to reproduce the issue. Another source informed us that it had the same issue and there was CalDAV client involved. I reviewed the code and I don't see what actions could lead to such invalid timezone entries. Here's a patch that we could use, but I think the issue is in another place:
--- a/plugins/calendar/calendar.php +++ b/plugins/calendar/calendar.php @@ -1974,6 +1974,8 @@ class calendar extends rcube_plugin */ private function write_preprocess(&$event, $action) { + $event['start'] = preg_replace('/\s*\(.*\)/', '', $event['start']); + $event['end'] = preg_replace('/\s*\(.*\)/', '', $event['end']); // convert dates into DateTime objects in user's current timezone $event['start'] = new DateTime($event['start'], $this->timezone); $event['end'] = new DateTime($event['end'], $this->timezone);
Jun 7 2017
Search for files with content "FLE Daylight Time" in /var/spool/imap/domain/ and provide a sample file.
Any tips how to best debug this issue?
Jun 6 2017
I've replaced the https_check() function with
As far as I can trace the calls back... our old friend api_url() is used to create the base URL and the scheme depends only on rcube_utils::https_check() and nothing else.
If the scheme "http" is used this can only mean, that rcube_utils::https_check() returned false - please correct me, if I'm wrong. Perhaps we should have a look at it next.
I've changed the file_api_url setting to some nonsense for testing purposes... Of course, it does not work, but the changed URL is passed along.
I've created a new text file and tried to open it. Same issue :-(
In this case it is Roundcube connecting to Chwala directly. It looks like the config has been ignored. I have no idea how's that possible. Maybe there's something in between that caches the request and returns old response? Check with a different file.
Is there anything I can do to help you to diagnose it?
I've set in kolab_files.inc.php
But it should work if you set file_api_url to a full url with https:// prefix? Do you set options in /etc/roundcubemail/config.inc.php? I'm unable to reproduce.
Yes, I've set use_https to true and applied the mentioned fixes. I'm sorry, but the issue persists :-/
And that is with use_https=true? BTW, there's another fix: rC0349c2d84661.
Now the error is away. Thank you!
Ok, try this change: rCd0539d6f029d.
I don't see how $_SERVER['SERVER_PORT'] == 80 would make it appended to the url. The if statement requires it to be different than $port and than 80. Maybe we should use intval($_SERVER['SERVER_PORT']).
I've written out $_SERVER['SERVER_PORT'] ... it's port 80. I assume that rcube_utils::https_check() returns true, so $schema is "https", this leads to $port = 443 and to a true, when evaluating the new if-block. So the port is appended to the hostname.
I've done just copy & paste. The code of the resulting function is ...
Maybe you just applied the patch incorrectly. Note the dot character in this line:
$url .= ':' . $_SERVER['SERVER_PORT'];
Forget my last comment. There's no such thing like $_SERVER['HTTP_PORT'].
Hmm... I'm just thinking. Maybe in your env you don't have $_SERVER['SERVER_PORT'] set either. Then try replacing this with $_SERVER['HTTP_PORT'].
What if you replace $_SERVER['SERVER_NAME'] with $_SERVER['HTTP_HOST']?
Thank you for the fix, but it doesn't seem to work :-/
Hope rCd886aeac2aec fixes that.
Jun 5 2017
Setting use_https to true does has not the desired effect. The created URL now contains the scheme "https", but it still uses port 80. Other parts of the application now complain about errors like this one:
May 31 2017
That's the problem. The error in question hasn't happened to me, so i don't know the exact steps to reproduce. What I've heard is that "it just happens automatically". When the recipient gets the calendar invitation email, the placeholder event is automatically created in the calendar (per kolab policy settings), and when the recipient user tries to accept/reject the invitation from the kolab roundcube webmail *calendar* application he gets the Internal Server Error and the PHP Fatal Error and the stack trace I posted can be found from the logs.
Fixed. You now would need to set use_https to true or file_api_uri to full chwala api path.
May 30 2017
The fix is in roundcubemail-plugins-kolab repo.
Fixed in rRPKce9ac27d783d.
Looks like rC21f6abd52a929 broke compatibility with Roundcube 1.2. Looks like we have now 3 options:
- Revert the change and wait with Roundcube 1.3 support until it's in Kolab, then apply it again
- Copy blank.tiff to blank.tif in roundcubemail package
- Use chwala URL to access these files.
May 29 2017
But this object has valid dates. So, how do I reproduce the issue?