Superseded by https://obs.kolabsys.com/request/show/3262, which includes an additional fix for the upgrade path by adding a conflict with roundcubemail-plugins-kolab.

Fix proposed in https://obs.kolabsys.com/request/show/3261. @machniak, @mollekopf, could you please take a look and push it through to Kolab:16 if it's okay?

Looks like fixed versions have been rolled out.

Fixed in roundcubemail-selfcontained

Did you ever get this fixed? I have the same issue as your last comment.

It appears I have right royally messed something up.

Yes - I assumed this and have already tried.
I literally can't do anything to remove this.

The ldap group information is cached, by default for 10 minutes. Check ldap_cache and ldap_cache_ttl settings. You can disable the cache with $config['ldap_cache'] = null;.

This has been fixed in Roundcube 1.3.4/1.4-beta.

Case 1 is already implemented.

It's part of Kolab 16.

Fixed in 668ca02c3f3d8 [roundcubemail master].

I confirm. This is for the Kolab skin based on Larry. Looks like it is caused by some style in Larry. The responsive skin has no such issue.

This should now have been resolved in packaging.

This should be resolved in packaging.

@dlford Thank you for posting and giving me the necessary pointers. I now have the calendar working. These were the steps I took on my CentOS 7 setup:

@chaser these are the steps I took get get it working in a test environment on Ubuntu 18.04. This is assuming your running Roundcube installation is at /var/www/html/roundcubemail so you may have to adjust the commands if it is somewhere else.

Because jsTimezoneDetect is not very active project I decided to add a workaround on PHP side. Fixed in https://github.com/roundcube/roundcubemail/commit/36485dfc345ad724f08eaa7ea30c3cc88e48a00d.

I'm seeing the same issue. Other than switching skin, is there any workaround for this?

Fixed in e85ff388293.

@vanmeeuwen /usr/share/roundcubemail/public_html/assets/plugins/libkolab/skins/elastic/libkolab.css is missing. So, it looks like a packaging issue.

plugins/calendar/calendar.php:

function load_settings()
{
[…]
    $settings['itip_notify'] = (int)$this->rc->config->get('calendar_itip_send_option', $this->defaults['calendar_itip_send_option']);
    $settings['week_numbers'] = 1;  // FIXME, needs to be similar like the line above
[…]
}

Not sure what is meant by "real estate", but my resolution is 1366x768, just to have it mentioned here.

Okay, I spent now some time with the code: My whole suggestion is already implemented, there are both, "weekNumbers" and "weekNumberTitle" variables in "plugins/calendar/lib/js/fullcalendar.js" which are later used by "plugins/calendar/calendar_ui.js".

Ok, I see now. libkolab.css is not added to the page. I don't know why yet, maybe something related to assets_dir.

@machniak; since we can reproduce this on webmail.kolabsys.com, I can verify there's no discernible error in the console.

In T4241#62348, @rsc wrote:

Closing this as invalid is not nice.

Closing this as invalid is not nice. It would be really helpful to have at least the second proposal done, given it adds no new screen space requirements. Aside of that, just having calendar weeks in mini-calendar is not really helpful when really actively working with the calendar a lot. Please consider reopening.

The week number is already included in the miniature calendar on the left-hand side, for both month and week views.

I have no idea. @rsc check browser console for errors.

There was an upstream ticket that has been closed. https://github.com/roundcube/roundcubemail/issues/6376

@rsc; what is the size of the real estate so we can attempt to reproduce?

This can be reproduced reliably.

Thanks to Jeroen for fixing roundcubemail in Winterfell, it is now working fine, my nightly tests succeed again!
Thank you!

The first error is something internal to composer. In my CentOS system I have composer-1.0.0-3.1.el7.kolab_wf and I have /usr/share/php/Psr/Log/LoggerInterface.php file.

I tried with --no-dev, but that did not seem to make a difference.
Then I tried to upgrade to Composer 1.2.4, which is the version used in Debian Stable: https://obs.kolabsys.com/package/show/home:tpokorra:branches:Kolab:Winterfell/composer

Maybe the composer version is too old. Many dependencies require phpunit using version constraint "^4" or similar. I think you can solve this simply by excluding developer dependencies. Use composer with --no-dev argument.

I have now built the roundcube package with the -complete tarball, in https://obs.kolabsys.com/package/show/home:tpokorra:branches:Kolab:Winterfell/roundcubemail

Since Roundcube 1.3 external javascript libraries are not anymore in the git repository. There's a script to download them and install in bin/install-jsdeps.sh (it uses jsdeps.json file in root folder). So, either we use -complete tarball (not /vendor folder there) or fetch js deps in package create stage. Or maybe in post-install script?

Fixed in a60c81d1b [master] and f9151f6830 [release-1.2]

Fixed in bf4326c834 [master].

That looks like simple mistake in the code. Fixed in rRPKc2e8cc16abf3.

I was investigating a similar case - create event in Gmail and invite 2 attendees - one for user with Outlook and one for user in Roundcube. Both accept the invitation, but user who accepted it in Roundcube is not marked with a check box in Gmail.
it turns out, that Roundcube sends possibly wrong DTSTAMP in meeting acceptance iTip. Comparing responses I noticed that original invitation from Gmail has

METHOD:REQUEST
DTSTAMP:20170627T054332Z
CREATED:20170627T054331Z
LAST-MODIFIED:20170627T054331Z

Acceptance iTip coming from Outlook has:

METHOD:REPLY
CREATED:20170627T054452Z
DTSTAMP:20170627T054452Z
LAST-MODIFIED:20170627T054452Z

But Roundcube sends iTip with:

METHOD:REPLY
DTSTAMP:20170627T054331Z
CREATED:20170627T054331Z
LAST-MODIFIED:20170627T054331Z

It is one second behind from DTSTAMP value in invitation. If I send exactly the same response as Roundcube did, but modify DTSTAMP to be at least the same value as it was in invitation, then Gmail records the status of the attendee.
RFC5545 says that:

In the case of an iCalendar object that specifies a "METHOD"
property, this property differs from the "CREATED" and "LAST-
MODIFIED" properties.  These two properties are used to specify
when the particular calendar data in the calendar store was
created and last modified.  This is different than when the
iCalendar object representation of the calendar service
information was created or last modified.

I'm not sure I fully understand what they want to say here, but to me it looks like:

• DTSTAMP in REPLY should be later than it was in REQUEST
• DSTAMP should be different from CREATED and LAST-MODIFIED

1. So, the iTips differ not much. I don't think CLASS:PUBLIC is relevant.
2. I think it's possible. When the event time changes client could request "re-sheduling". You'd need to see what's in G's iTip in step 4.

In T2504#37355, @machniak wrote:

We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.

Back to your questions:

1. No idea. Check Itip payload.

Event which doesn't make GMail Calendar record attendee status as accepted

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN
CALSCALE:GREGORIAN
METHOD:REPLY
BEGIN:VEVENT
UID:i698fn56cjct6tvjt3sfa2m6j0@google.com
DTSTAMP:20170621T091446Z
CREATED:20170621T091446Z
LAST-MODIFIED:20170621T091446Z
DTSTART:20170622T040000Z
DTEND:20170622T050000Z
SUMMARY:KS Demo =C4=97
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
SEQUENCE:0
TRANSP:OPAQUE
STATUS:CONFIRMED
ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA=
NT;CUT
 YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld
ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com
END:VEVENT
END:VCALENDAR

Event which makes GMail record attendee status

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Roundcube libcalendaring 1.2.5//Sabre//Sabre VObject 3.4.5//EN
CALSCALE:GREGORIAN
METHOD:REPLY
BEGIN:VEVENT
UID:i698fn56cjct6tvjt3sfa2m6j0@google.com
DTSTAMP:20170621T091716Z
CREATED:20170621T091446Z
LAST-MODIFIED:20170621T091716Z
DTSTART:20170622T040000Z
DTEND:20170622T060000Z
SUMMARY:KS Demo =C4=97
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
SEQUENCE:0
TRANSP:OPAQUE
STATUS:CONFIRMED
CLASS:PUBLIC
ATTENDEE;CN=3Dkolab.systems@domain.tld;PARTSTAT=3DACCEPTED;ROLE=3DREQ-PARTICIPA=
NT;CUT
 YPE=3DINDIVIDUAL:mailto:kolab.systems@domain.tld
ORGANIZER;CN=3DLiutauras Adomaitis:mailto:organizer@gmail.com
END:VEVENT
END:VCALENDAR

We'd need to see iTip payload. I guess that in step 4, the event is in "re-sheduling" mode, i.e. the attendee status is re-set to NEEDS-ACTION. In such a case (and settings) wallace will not respond with ACCEPT. I have no idea what could be different in iTip replies sent in step 2 and 6.

It is possible to preview or download attached files from mail compose screen in Roundcube 1.3. So likely a Kolab 18 feature.

Net_Sieve taken over. So, we can keep using pear/Net_Sieve. Note that for PHP7 support version 1.4.0 is required.

https://github.com/pear/Net_Sieve/pull/5 for reference. However, I'll try to take over the package and backport our fixes to it anyway.

The original Net_Sieve author abandoned the package and didn't want to fix it. That's why we forked. As for the pdo, openssl, session, json, pcre, these are php extensions, I didn't check package names for them.

Roundcube 1.2:

• don't require pear's MDB2, Mail_mimeDecode, nor DB,
• don't require php-mcrypt,

Solved by setting the timezone value in capitals in /etc/php.ini

Yes, there are errors about the timezone settings:

That is version of roundcubemail-plugins-kolab, there should be roundcubemail package too, but nevermind.

There are a lot of roundcubemail packages, can be a bit more exact about from which package you would like to know it? The version most mentioned is 3.3.0-4.1

What roundcubemail package version? Could you provide a sample eml file? Any error in log?

On PHP7 (Ubuntu Xenial) we see:

[10-May-2017 12:57:43 Europe/Berlin] PHP Deprecated:  Methods with the same name as their class will not be construc
tors in a future version of PHP; Net_Sieve has a deprecated constructor in /usr/share/php/Net/Sieve.php on line 93
[10-May-2017 12:57:43 Europe/Berlin] PHP Warning:  array_merge(): Argument #1 is not an array in /usr/share/php/Net/
Sieve.php on line 312

these are fixed in the Roundcube's fork of Net_Sieve. We should provide that in packaging.

I started to package endroid-qrcode for Debian and saw that there is a new upstream release 1.6.5 available. The changelog has:

It actually is Roundcube core change. This was partially fixed in git-master. Fixed in release-1.1 with commits: 6fb8da08f, 1123f39cf and 9b8db4c9e.

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

Thank you for the hint with the "Empty" action. I did not know about that!