Fixed.

@adomaitis Looks like both DayOfWeek and Until are optional. In this case I think we just should not include DayOfWeek in the response. Did you test that?

Not exactly the same error, but we have already T2163.

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.

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.

FYI, Collabora Online 2.1.2 added support for avatars and custom button. So, technically it should be possible to move all our functionality into the editor frame.

Fixed.

SendResponse element was added in version >=16.0 of the ActiveSync protocol, which means it is optional and can be excluded from the initial implementation. Also, from what I see it is about calendar events. I didn't found any information about handling of iTips for TODO (tasks), so they are probably ignored.

Add note about uid and changed fields

One additional change is required in the ldap_public config:

Note: To make the LDAP addressbook sources working we need two additional
	//       fields ('uid' and 'changed') specified in the fieldmap array
	//       of the LDAP configuration ('ldap_public' option). For example:
	//          'uid'     => 'nsuniqueid',
	//          'changed' => 'modifytimestamp',

Describe new blacklist and GAL options

This is done. Required configuration for Outlook:

$config['activesync_gal_sync'] = array('windowsoutlook');
$config['activesync_multifolder_blacklist_contact'] = array('windowsoutlook');

1-3 is fixed via merged D204.

Search for files with content "FLE Daylight Time" in /var/spool/imap/domain/ and provide a sample file.

Fixed.

Fixed.

Fixed.

https://git.kolab.org/diffusion/C/browse/master/lib/viewers/text.php;0349c2d846613e4c828ed6f7af00b87ed6a75f79$120

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.

Page refresh should fix the issue. This is a regression that is not so simple to fix. My first take on this failed.

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.

And that is with use_https=true? BTW, there's another fix: rC0349c2d84661.

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']).

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']?

Hope rCd886aeac2aec fixes that.

While using constant folder identifiers would be good long term solution, in meantime I've found a simpler way. With rS57c38b7aede3 the device will correctly handle folder renames and re-synchronize folder hierarchy and renamed folder content. Closing.

@seigo I'm done with this for now, will be busy with other stuff now, so you can merge this and continue. I added presence to room channel, but commented out, as I'm not sure we really need it there.

Refactor Presence

• Store channel metadata (basics with :ets use)

Fixed.

Fixed. You now would need to set use_https to true or file_api_uri to full chwala api path.

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

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:

1. Revert the change and wait with Roundcube 1.3 support until it's in Kolab, then apply it again
2. Copy blank.tiff to blank.tif in roundcubemail package
3. Use chwala URL to access these files.

But this object has valid dates. So, how do I reproduce the issue?

Fixed in cae366edcab1b.

Activesync supports reminders (alarms) only as "the number of minutes before a calendar item start time". So, we can just ignore these alarms or check if the datetime is before start time of the event and calculate number of minutes.

Fixed in:

• chwala e412536b1b6 [master] and 04ff2737dc [chwala-0.4].
• roundcubemail-plugins-kolab f357819dd0 [master].

I'm not sure what issue do you have with email, but files are indeed stored with timestamps in UTC. The plugin displays the date as-is provided by chwala. It will be chwala's responsibility to convert it to user timezone (if provided). The timezone would need to be passed by Roundcube to chwala first.

I can't reproduce the issue by importing the .ics file. Could you provide the object in xml format (i.e. the message from imap folder)?