Hi, thanks for the update.

Bugs logged there are not considered here, they need to be logged here.

I think we'd need a change around https://git.kolab.org/diffusion/C/browse/master/lib/api/common.php$237, but I didn't think about it yet.

I did some debugging in the seafile_file_storage class.

Okay I’ll take a look on it later. I guess it’s this part:
https://git.kolab.org/diffusion/C/browse/master/lib/drivers/seafile/seafile_file_storage.php$918

That scenario is not supported because you can't store config and you can't use cache without kolab backend. You could probably live without these in some setups, so yes in theory it should work. There must be a bug somewhere.

Hmmm But in theory it could work. I get the list of repositories. Chwala works correctly and lists all folders. Just kolab_files doesn’t get over it and doesn’t request the subfolders of each repo which is presented. BTW the files on the roots of each repo are shown as well.

... and we should throw an error when fileapi_backend != 'kolab'.

I think we should finally remove that section from documentation. It is not supported scenario, I think it is not even supposed to work. There's a comment in sample config:

// Main files source, backend driver which handles
// authentication and configuration of Chwala
// Note: Currently only 'kolab' is supported
$config['fileapi_backend'] = 'kolab';

Basically exactly like described in the howto: https://docs.kolab.org/howtos/use-seafile-with-chwala.html?highlight=seafile#using-seafile-as-an-exclusive-storage-mechanism

Yes, kolab_files uses now different (semi-recurrent) logic to fetch folders hierarchy. How exactly did you configure chwala with seafile?

Please do consider taking this to whatever the appropriate priority actually is, or however else you keep it off my radar until such time there's some meaningful involvement on my part ;-)

Correcting the priority from 60/40 to Normal

This ticket is no longer relevant.

This seems like low-priority aesthetics to me more so than an actual problem.

We do not actively support the database backend driver, so please bear in mind this has a very low priority for us.

Fixed in cbd1c1ae47b9.

The issue is fixed in dev/fullcalendar-upgrade branch. It will be merged soon.

In T4776#68850, @machniak wrote:

Unfortunately an update is not trivial.

Confirmed. This is a known bug in fullcalendar library. Unfortunately an update is not trivial.

Fixed in e85ff388293.

Probably it could, but in reality it doesn't make a big difference if you consider return value of both on kolab_storage_folder_user.

@vanmeeuwen Spaces and unicode are perfectly allowed in attachment names thanks to the RFCs about encoding the names in headers. The ticket is about iTip attachments specifically. I confirm that the code removes all non-ascii characters making the attachment name completely dummy in some cases. I don't really know why @bruederli make it this way. Maybe there was a reason.

Maybe I wasn't clear about what I would like to see: Roundcube's config/defaults.inc.php has by default this:

There is "'d.M'," vs. "'d.M.'" (note the second dot).

I'm not understanding what the difference is between;

Compatibility with other clients basically requires (read: "has required"?) file names for attachments are ascii-encoded and do not contain spaces. I think there's even an RFC on client-compatible naming conventions for naming attachments, but I'm failing to recall the number (maybe 2138?).

Copenhagen is, in principle, available. The reason for the parent ticket to exist has largely been obsoleted. This sub-ticket, and its sub-tickets, can therefore be closed.

According to code it looks intentional, but I don't know a real reason, maybe there was some interoperability issue. Honestly, I don't see a reason to not use unicode.

I fixed this yesterday in commit 91b071d1530b [roundcubemail-plugins-kolab master].

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
[…]
}

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".

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.

Patch applied in 239783c3dd576.

Done.

That is fine with me. I don't expect anything more fancy in this case.

Actually a cancelled event has text-decoration:line-through on the title, but when the event's height takes only one time slot that title is not visible. I don't think we should display them "in white" as we do for pending/declined events, so I propose to just add opacity:0.6.

@adomaitis this depends on some earlier commit: https://git.kolab.org/rRPK2ad0d6651dfbcb32c146465ad9539848b285e3f9

I see some odd behavior after applying this patch

Uncaught TypeError: me.has_attendees is not a function
    at update_event_confirm (https://mail.fsi.io/webmail/assets/plugins/calendar/calendar_ui.js:2512:29)
    at HTMLDivElement.eventDrop (https://mail.fsi.io/webmail/assets/plugins/calendar/calendar_ui.js:3799:9)
    at Calendar.trigger (https://mail.fsi.io/webmail/assets/plugins/calendar/lib/js/fullcalendar.js:1:10028)
    at trigger (https://mail.fsi.io/webmail/assets/plugins/calendar/lib/js/fullcalendar.js:3:21529)
    at eventDrop (https://mail.fsi.io/webmail/assets/plugins/calendar/lib/js/fullcalendar.js:3:23804)
    at HTMLDivElement.stop (https://mail.fsi.io/webmail/assets/plugins/calendar/lib/js/fullcalendar.js:3:4398)
    at t.(anonymous function).(anonymous function)._trigger (https://mail.fsi.io/webmail/assets/plugins/jqueryui/js/jquery-ui-1.10.4.custom.min.js:36:10036)
    at t.(anonymous function).(anonymous function)._trigger (https://mail.fsi.io/webmail/assets/plugins/jqueryui/js/jquery-ui-1.10.4.custom.min.js:36:29884)
    at t.(anonymous function).(anonymous function)._trigger (https://mail.fsi.io/webmail/assets/plugins/jqueryui/js/jquery-ui-1.10.4.custom.min.js:36:5029)
    at t.(anonymous function).(anonymous function)._mouseStop (https://mail.fsi.io/webmail/assets/plugins/jqueryui/js/jquery-ui-1.10.4.custom.min.js:36:23145)

and

Uncaught TypeError: me.has_attendees is not a function
    at event_edit_dialog (calendar_ui.js:697)
    at AgendaWeekView.select (calendar_ui.js:3743)
    at Calendar.trigger (fullcalendar.js:1)
    at trigger (fullcalendar.js:3)
    at reportSelection (fullcalendar.js:4)
    at HTMLDocument.<anonymous> (fullcalendar.js:2)
    at HTMLDocument.d (jquery.min.js:35)
    at HTMLDocument.dispatch (jquery.min.js:35)
    at HTMLDocument.r.handle (jquery.min.js:35)

is displayed several times in browser console.
Also I when I drag the event in attendees calendar I don't see any "saving..." box displayed in the corner as usual. I can't drag already dragged event once again.

Fixed by 0c02d0d45c6 in roundcubemail-plugins-kolab [master].

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..

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);

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.

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.

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?

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

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.