From cs at nnix.de Wed Oct 16 08:52:14 2024 From: cs at nnix.de (Christian Schwamborn) Date: Wed, 16 Oct 2024 10:52:14 +0200 Subject: [Kolab-devel] issue with custom timezones in invitations Message-ID: <286d784d-167d-6a15-517f-d4dbe8c209f4@nnix.de> Hello Aleksander, recently I got an invitation with a custom timezone. Curious as I am, I tested it on the roundcube calendar plugin (with the new caldav driver) and got not quite the intended result. The event was shown in the roundcube preview with 2024-10-22 9:30 - 10:00 (UTC) Accepting the event it was entered as 2024-10-22 11:30 - 12:00 local time, my timezone is CEST (UTC+2) which makes sense on first glance, but looking at the original ics there is a somewhat unconventional but I think valid timezone definition: (stripped out the superfluous stuff i.e. the X-MICROSOFT and the private data) BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Customized Time Zone BEGIN:STANDARD DTSTART:16010101T030000 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=4SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER... ATTENDEE... ... DESCRIPTION... UID... SUMMARY... DTSTART;TZID=Customized Time Zone:20241022T093000 DTEND;TZID=Customized Time Zone:20241022T100000 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20241015T055003Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:2 LOCATION... BEGIN:VALARM DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT15M ACTION:DISPLAY END:VALARM ... END:VEVENT END:VCALENDAR I honestly don't know why that server just used a standard time zone (cest in this case) and if that timezone definition is a general Microsoft thing, or if its just the strange configuration on this host (might be able to get a hold on the hosts admins). The calendars interpretation as UTC is incorrect, it doesn't know what exactly it is. Might be an easy solution just to say something like 'unknown timezone' and let the user guess and pick it, or it should be handled somehow but not just falling back to UTC. There where some other connected issues: 1. (I don't know if the client can influence this) even if you switch off the sender notification, systems like the nextcloud will send something to the organizer. 2. As the plugin offers the possibility to edit the event, I tried to change the time (with the warning that it's just a local change and the organizer would not be notified), but after the save the event was reloaded and appeared with the old (wrong) time. My guess: Nextcloud refuses to modify such events, usually that's the behavior I would expect, as an invitation can either be accepted, accept with reservation, or declined. 3. I finally deleted the invitation with switched off organizer notification, but a decline was sent anyway (again: I don't know if the client can influence this, if the caldav server handles the notifications) Is there some configuration how to handle invitations and notifications? Best regards Christian From jochen at jochen.org Sun Oct 27 06:23:46 2024 From: jochen at jochen.org (Jochen Kellner) Date: Sun, 27 Oct 2024 07:23:46 +0100 Subject: [Kolab-devel] Roundcube on Debian 12 - LDAP? Message-ID: <83ldyacbd9.fsf@jochen.org> Hi, I've upgraded to Debian12 and have problems logging into roundcube. I've enabled ldap-Trace in roundcube and see that there is a successful bind. But in the roundcube log: LDAP Error: Could not connect to any LDAP server in /usr/share/roundcubemail/plugins/libkolab/lib/kolab_ldap.php on line 227 (POST /roundcubemail/?_task=login&_action=login) The code is this: if (!is_resource($this->conn)) { rcube::raise_error(['code' => 100, 'type' => 'ldap', 'file' => __FILE__, 'line' => __LINE__, 'message' => "Could not connect to any LDAP server"], true); I've looked at the code for some time and didn's see where $this->conn is set. If I remove that code and just accept the first (only) LDAP server as working I can log in and roundcube seems to work. The code at that part didn't change recently... What do I miss? I'm also slightly confused which php-ldap modules are really neede in the os and what is right now vendored. Jochen -- This space is intentionally left blank. From machniak at apheleia-it.ch Sun Oct 27 07:40:27 2024 From: machniak at apheleia-it.ch (Aleksander Machniak) Date: Sun, 27 Oct 2024 08:40:27 +0100 Subject: [Kolab-devel] Roundcube on Debian 12 - LDAP? In-Reply-To: <83ldyacbd9.fsf@jochen.org> References: <83ldyacbd9.fsf@jochen.org> Message-ID: <769d279a-48a3-483f-a6b8-d3e0638dfe2e@apheleia-it.ch> On 27.10.2024 07:23, Jochen Kellner wrote: > LDAP Error: Could not connect to any LDAP server in > /usr/share/roundcubemail/plugins/libkolab/lib/kolab_ldap.php on line 227 > (POST /roundcubemail/?_task=login&_action=login) > > The code is this: > > if (!is_resource($this->conn)) { > rcube::raise_error(['code' => 100, 'type' => 'ldap', > 'file' => __FILE__, 'line' => __LINE__, > 'message' => "Could not connect to any LDAP server"], true); > > I've looked at the code for some time and didn's see where $this->conn > is set. If I remove that code and just accept the first (only) LDAP > se In PHP 8.1 LDAP connection has been changed from a reasource to an object. This condition is not correct any more. I just fixed this in https://git.kolab.org/rRPK8a7b4e249743334710ba153d926859eef93cd225 -- Aleksander Machniak Senior Software Engineer Apheleia IT AG PGP: 19359DC1 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From jochen at jochen.org Sun Oct 27 11:13:27 2024 From: jochen at jochen.org (Jochen Kellner) Date: Sun, 27 Oct 2024 12:13:27 +0100 Subject: [Kolab-devel] Roundcube on Debian 12 - LDAP? In-Reply-To: <769d279a-48a3-483f-a6b8-d3e0638dfe2e__47044.4799096853$1730014851$gmane$org@apheleia-it.ch> (Aleksander Machniak's message of "Sun, 27 Oct 2024 08:40:27 +0100") References: <83ldyacbd9.fsf@jochen.org> <769d279a-48a3-483f-a6b8-d3e0638dfe2e__47044.4799096853$1730014851$gmane$org@apheleia-it.ch> Message-ID: <83h68xdciw.fsf@jochen.org> Hello Aleksander, Aleksander Machniak writes: > On 27.10.2024 07:23, Jochen Kellner wrote: >> LDAP Error: Could not connect to any LDAP server in >> /usr/share/roundcubemail/plugins/libkolab/lib/kolab_ldap.php on line 227 >> (POST /roundcubemail/?_task=login&_action=login) >> The code is this: >> if (!is_resource($this->conn)) { >> rcube::raise_error(['code' => 100, 'type' => 'ldap', >> 'file' => __FILE__, 'line' => __LINE__, >> 'message' => "Could not connect to any LDAP server"], true); >> I've looked at the code for some time and didn's see where >> $this->conn >> is set. If I remove that code and just accept the first (only) LDAP >> se > In PHP 8.1 LDAP connection has been changed from a reasource to an > object. This condition is not correct any more. > > I just fixed this in > https://git.kolab.org/rRPK8a7b4e249743334710ba153d926859eef93cd225 Thanks a lot. I've applied the fix locally and could login. Jochen -- This space is intentionally left blank.