Confirmed. This is a known bug in fullcalendar library. Unfortunately an update is not trivial.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 17 2018
Nov 28 2018
Fixed in e85ff388293.
Sep 27 2018
Aug 23 2018
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:
Aug 22 2018
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?).
Aug 21 2018
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.
Aug 17 2018
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.
Aug 16 2018
Aug 15 2018
I fixed this yesterday in commit 91b071d1530b [roundcubemail-plugins-kolab master].
Aug 14 2018
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 […] }
Aug 13 2018
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.
Aug 7 2018
Mar 5 2018
Patch applied in 239783c3dd576.
Feb 5 2018
Feb 4 2018
Oct 21 2017
Sep 27 2017
Aug 29 2017
Done.
Aug 28 2017
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.
Aug 2 2017
Jul 18 2017
@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.
Jul 4 2017
Fixed by 0c02d0d45c6 in roundcubemail-plugins-kolab [master].
Jun 30 2017
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..
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);
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
Jun 22 2017
Jun 21 2017
- So, the iTips differ not much. I don't think CLASS:PUBLIC is relevant.
- 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:
- 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.
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
Page refresh should fix the issue. This is a regression that is not so simple to fix. My first take on this failed.
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.
May 30 2017
The fix is in roundcubemail-plugins-kolab repo.
May 29 2017
But this object has valid dates. So, how do I reproduce the issue?
I hope I didn't screw up the xml while removing private info.. but here goes:
http://pasik.reaktio.net/kolab-webmail-calendar-internal-server-error.xml
May 24 2017
No, K16 is enough
Fixed in:
- chwala e412536b1b6 [master] and 04ff2737dc [chwala-0.4].
- roundcubemail-plugins-kolab f357819dd0 [master].
The issue with emails is a user-confusion issue: you get an email with an attachment, you save that attachment "to the cloud", and now the time is oddly different than the email. So it isn't that there is a bug with emails, but that the time differences cause problems for users.
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)?
May 23 2017
Sorry took a while, but now it happened again..:
May 18 2017
Apr 11 2017
I delete the config directory and rebuilt the mail box, every thing is back to normal.
Apr 7 2017
Fixed.
No, wait. I see now that if you just visit the Resources tab doing nothing works, but if you visit the tab and add any resource to the event, then the organizer is not set in the Participants tab. T1484 fix is relevant here in a way that the organizer will be set anyway by the backend code. So, it's only frontend issue.
Apr 4 2017
Fixed in dfacbe01bca [master] and acc49b51fff [roundcubemail-plugins-kolab-3.2].
Apr 1 2017
The best would be to see the whole message. You can remove private data.
Which parts of the XML are important? I can try to find it..
Mar 30 2017
Kolab Plugins
Is there a chance we can see the original event data in XML form or as iCal export? Anyway, I suppose a needed fix here will be to remove the timezone string in brackets before passing it to the DateTime constructor.
Mar 27 2017
Pykolab version is irrelevant here. What roundcubemail-plugins-kolab version? We had such an issue in the past, but it was hard to find the reason of it. I didn't hear about the issue recently, so maybe it's fixed or maybe not. To remove the tags you have to visit the Configuration folder and remove redundant objects. Do this in command line and then reconstruct the mailbox.
Mar 18 2017
Just in case, more rpm versions:
Mar 6 2017
Sounds like a duplicate of T1484.
Feb 20 2017
Jan 4 2017
I'm unable to reproduce this with Roundcube Calendar. So, it might be already fixed or the bug is in iRony.
Jan 3 2017
Looks like none of libkolabxml and plugins: libkolab and calendar support BYSETPOS. As a quick fix we should probably allow two simple and most common cases of "first weekday" and "last weekday" by converting them to correct BYDAY property.