Closed Bug 1560151 Opened 5 years ago Closed 3 years ago

Got a VALUE parameter with an illegal type for property: VALUE=DURATION

Categories

(Calendar :: Import and Export, defect)

Lightning 6.2
defect
Not set
normal

Tracking

(thunderbird_esr78 fixed, thunderbird90 fixed)

RESOLVED FIXED
91 Branch
Tracking Status
thunderbird_esr78 --- fixed
thunderbird90 --- fixed

People

(Reporter: steve.b, Assigned: josselin.dulac)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36 OPR/60.0.3255.170

Steps to reproduce:

Thunderbird+Lightning updated; started getting this error.

Reinstalled Lightning; still got this error.

Actual results:

Export of an event with an alarm:

.
.
.
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-P1D
DESCRIPTION:Default Mozilla Description
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
END:VALARM
.
.
.

Expected results:

Why is that error happening? Shouldn't I just get exported:

.
.
.
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-P1D
DESCRIPTION:Default Mozilla Description
END:VALARM
.
.
.

If I redact those errors, the export is understood by other programs...

I can confirm this bug.

Thunderbird version: 60.7.2 (64-bit) on opensuse Leap 15.0
Lightning version: 6.2.7.2

Lightning version 6.2.6.1 was still OK.

It even "trashes" the calender database (local.sqlite) in TABLE cal_alarms.
An effected row from cal_alarms:
INSERT INTO cal_alarms VALUES('8aaa5010-05dc-4d31-84db-239e6cf459de','1dce165d-06f5-490b-9a33-4e5f50ccfcaf',NULL,NULL,replace(replace('BEGIN:VALARM\r\nACTION:DISPLAY\r\nTRIGGER;VALUE=DURATION:-P1D\r\nDESCRIPTION:Default Mozilla Description\r\nX-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parame\r\n ter with an illegal type for property: VALUE=DURATION\r\nEND:VALARM\r\n','\r',char(13)),'\n',char(10)));

Confirmed again here. TB 60.8.0 on Ubuntu19.04. Lightning 6.2.8.

Suspect Bug 1566908 is a duplicate of this bug.

Can you retest this on Thunderbird 68?

Flags: needinfo?(steve.b)

Appears to have stopped. But I am using version 60.9, and it says in Help...About that I am up to date.

And yet, when I go to the download site,it offers me version 68?

Will install it...

Flags: needinfo?(steve.b)

That works too.

I can stop editing my exports now; thanks...

I'm using 68.1.1 and the error is still there when I export my calendars:

BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT10M
DESCRIPTION:Default Mozilla Description
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parame
ter with an illegal type for property: VALUE=DURATION
END:VALARM

(In reply to Steve B. from comment #6)

That works too.

I can stop editing my exports now; thanks...

I spoke too soon! It has reappeared.

Odd: I did see it go away when you contacted me. Perhaps a previous version fixed it, but the latest reintroduces the error...

Thunderbird 68.1.2 (64-Bit)
Lightning 68.1.2

Can confirm the behavior.
My Thunderbird Calendar is connected to SoGo 4.0.2 via CalDav by using TbSync 2.5 / CalDAV & CardDAV provider for TbSync 1.4
I have done the following:

  • Exported the Calendar out of Thunderbird. Lots of calendar entries includet the folowing error:
    X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
  • Deleted all error entries in the exported .ics file with an text editor
  • Deleted all entries in Thunderbird calendar and synced with SoGo (all entries disappered in Thunderbird and SoGo)
  • Imported the above edited calendar .ics file in Thunderbird and synced with SoGo.
  • Exported the Calendar out of Thunderbird and Sogo again. In both exported .ics files there are the following error entries existing again:
    X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
  • Made a new test calendar entry in Thunderbird WITHOUT a reminder entry. Exported the Thunderbird and SoGo Calendar again. There
    have been no error entries in both .ics files.
  • Made a new test calendar entry in Thunderbird WITH an reminder entry. Exported the Thunderbird and SoGo Calendar. The error entry
    appears in the thunderbird .ics export file but NOT in the SoGo .ics export file.

Note: The calendar entries witch include the X-LIC-ERROR entries are not synced with my Android 9 smartphone via SoGo activesync. The entries are not visible in the android calendar.

Hope this helps a bit.

updated to
Thunderbird 68.2.0 (64-Bit)
Lightning 68.2.0

No change, same behavior...


(In reply to chapderprinz from comment #9)

Thunderbird 68.1.2 (64-Bit)
Lightning 68.1.2

Can confirm the behavior.
My Thunderbird Calendar is connected to SoGo 4.0.2 via CalDav by using TbSync 2.5 / CalDAV & CardDAV provider for TbSync 1.4
I have done the following:

  • Exported the Calendar out of Thunderbird. Lots of calendar entries includet the folowing error:
    X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
  • Deleted all error entries in the exported .ics file with an text editor
  • Deleted all entries in Thunderbird calendar and synced with SoGo (all entries disappered in Thunderbird and SoGo)
  • Imported the above edited calendar .ics file in Thunderbird and synced with SoGo.
  • Exported the Calendar out of Thunderbird and Sogo again. In both exported .ics files there are the following error entries existing again:
    X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
  • Made a new test calendar entry in Thunderbird WITHOUT a reminder entry. Exported the Thunderbird and SoGo Calendar again. There
    have been no error entries in both .ics files.
  • Made a new test calendar entry in Thunderbird WITH an reminder entry. Exported the Thunderbird and SoGo Calendar. The error entry
    appears in the thunderbird .ics export file but NOT in the SoGo .ics export file.

Note: The calendar entries witch include the X-LIC-ERROR entries are not synced with my Android 9 smartphone via SoGo activesync. The entries are not visible in the android calendar.

Hope this helps a bit.

I am also struggling with this error - half of my calendars is not working anymore...

No change, same behavior in recent Thunderbird 68.2.2 (64-bit)

Firefox 68.5.0
Lightning 68.1.2

I just got the same error.

Because of another issue with lightning, I decided to export all calender events. When I opened the ICS file, I noticed that almost all event entries have the above mentioned error.

Have these lines in my ics export and in the caldav server side too - I cannot tell, how they got there, but they seem no problem

Starting thunderbird from a terminal I see that:

console.warn: Lightning: Parsing failed for parts of the item (while this is considered to be a minor issue, we continue processing the item):

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
…
BEGIN:VEVENT
…
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT30M
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parame
 ter with an illegal type for property: VALUE=DURATION
END:VALARM
END:VEVENT
END:VCALENDAR

Note: Only the first line is the error message, the line with ERROR is actually part of the event! The value though is fine.

I am seeing this now with a CalDav calendar and Thunderbird 78.3.1
Relevant part from error console

Lightning: CalDAV: Unexpected status modifying item to RH: 403
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Warsaw
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T010000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20200513T135102Z
LAST-MODIFIED:20201008T092815Z
DTSTAMP:20201008T092815Z

......

X-LIC-ERROR:No value for LOCATION property. Removing entire property:
SEQUENCE:1
TRANSP:OPAQUE
X-MOZ-GENERATION:1
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT10M
DESCRIPTION:This is an event reminder
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
END:VALARM
END:VEVENT
BEGIN:VEVENT
CREATED:20200513T135102Z
LAST-MODIFIED:20201008T083606Z
DTSTAMP:20201008T083606Z
UID:fsqsbahrj0k6kbs24dki1bd78u@google.com
SUMMARY:MW CPaaS Sync
STATUS:CONFIRMED
RECURRENCE-ID;TZID=Europe/Warsaw:20201019T110000
DTSTART;TZID=Europe/London:20201019T100000
DTEND;TZID=Europe/London:20201019T103000
END:VEVENT
Status: UNCONFIRMED → NEW
Ever confirmed: true

Probably of interest: The X-LIC-ERROR line is not in the ics exported from the caldav server, but it is in the ics exported from lightning. I suppose that it only marks, that lightning got a parsing error in one of the preceding lines. Plus: it seems to always be about a TRIGGER.

Here to the spec, https://icalendar.org/iCalendar-RFC-5545/3-8-6-3-trigger.html

  • TRIGGER;VALUE=DURATION:-PT10M looks legit, it is a relative alarm

The ;VALUE=DURATION part is optional though. TRIGGER:-PT10M would do as well. Probably the ics parser just does not like it spelt out in full.

Happy to provide further output / test things if it would be useful!

I'm also affected by this, happy to provide help in debugging it.

Can confirm this still occurs in TB78.3.1.

I did an export of all my local calendars with TB78.5.1.
Each DURATION param is listed as
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION

I experience the same with TB 68.10.0 (64-bit) on Linux Mint 20 Cinnamon (64-bit).
Five local calendars are going crazy by reminding me of undeletable reminders, many appointments are lost or cathegories altered & the like.
In the exported *.ics-file I find exactly the same X-LIC-ERROR.

Is there any workaround?
It is in fact impossible to deal with the load of undeletable reminders that count into the dozens meanwhile.

My current assessment of this bug is that it will never be fixed because if you use Google Calendar they have a server side fix for this already and seeing as they sponsor development, I don't think they want it to be fixed.

This breaks other CalDav implementations but that doesn't matter after almost 2 years.

Have all "Mozilla" projects and products became just a Google excuse for not being a monopoly with no real drive to fix things?

Bill, I'm sure patches are welcome.

If you are not a developer yourself, or don't have time to work on this, perhaps you should consider funding the work yourself, for example by posting a bounty at https://www.bountysource.com/issues/95686166-1560151-got-a-value-parameter-with-an-illegal-type-for-property-value-duration.

I've been poking around a little and it appears to me that the parsing error was introduced in the fix for bug 1555646. The fix backported a commit to the upstream libical to do the type validation, but the libical version was changed shortly afterwards to use a generated table, so they won't have noticed that the DURATION case for TRIGGER was missing. Those changes are quite invasive, but simply adding DURATION to the type check might be enough to fix the current problem.

Is there something new on this topic? I can't believe that this bug isn't fixable for years now. :/ PLEASE! I'm hoping on every update.

After 2 years of Mozilla Thunderbird messing up my davical and repeatedly having to clean it up so that my Android devices would sync again, I took the hard decision (I've been using it since the early 2000s) to stop using it and switched to another mail client.
Removing myself from the notifications too. This is the second time this year I've stop using one of Mozilla's projects, the other being Firefox on Android, what a dog's dinner that has turned out to be.
Good luck Mozilla.

My experience with the "bug" is, that it is just a nuisance for the people, that read logs, like myselves from time to time. From what I can tell, the data fully conforms to the specification, only broken clients (mentioned android apps) will fail on it. Eg. neither davical nor DAVx⁵ have any problems.

I think, wasting time dealing with undeletable reminders is an inconvenience nobody needs.
To get rid of this, you need to downgrade on a backup, naturally always losing changes made since then.
Exporting the buggy bunch and reimporting it into a clean installation results in the same error.
Editing doesn't help.
After weeks I decided to go through by hand an restore what I could out of my analogue backup.
So, I take this bug serious.
Nobody in charge seems to.
This doesn't speak for bugzilla.
Or does it?

(In reply to jockel from comment #32)

I think, wasting time dealing with undeletable reminders is an inconvenience nobody needs.
To get rid of this, you need to downgrade on a backup, naturally always losing changes made since then.
Exporting the buggy bunch and reimporting it into a clean installation results in the same error.
Editing doesn't help.
After weeks I decided to go through by hand and restore what I could out of my analogue backup.
So, I take this bug serious.
Nobody in charge seems to.
This doesn't speak for bugzilla.
Or does it?

(In reply to Hungerburg from comment #31)

My experience with the "bug" is, that it is just a nuisance for the people, that read logs, like myselves from time to time. From what I can tell, the data fully conforms to the specification, only broken clients (mentioned android apps) will fail on it. Eg. neither davical nor DAVx⁵ have any problems.

Considering that most people also have an Android or Apple phone, then it should be of concern to Mozilla that such a basic function breaks other clients (regardless of "broken" they might be in Mozilla's opinion).

You can only afford that level of contempt for you users if you are not dependant on your product being loved and a success. Wait, who is paying Mozilla loads JUST that they exist so declaring a monopoly is more difficult .... hmmm.

How do you break thousands of plug-ins? One of the things the product was once highly praised for? Ask Mozilla . . .

As I said before, look what they did to Firefox on mobile, and how Thunderbird has been pushed to the side, to the point that there was even discussion about giving up on it and moving it to a different project/company outside of Mozilla.
As I said previously, I started using this when Netscape gave it Mozilla having previously used Netscape. It takes quite a bit to get someone that has been using the product for over 20 years to "enough is enough". Yes I'm salty, no wonder.

I'm trying out evolution (Cinnamon/Gnome) and Kmail (KDE) now, and it looks like I'll be going in the direction of Evolution.

Hello,
I don't have time right now to dig into all the stuff to properly propose a patch, but I assume changing those lines in the file icalparser.c (line 1029-1033 in the current version) would work

            /* Accept DATE-TIME and DURATION */
            if (value_kind != ICAL_DATETIME_VALUE && value_kind != ICAL_DURATION_VALUE)
                value_err = illegal_type;
            break;

direct link to the file https://searchfox.org/comm-central/source/calendar/libical/src/libical/icalparser.c#1029

If an active developer can add this patch, it would be very great (this bug is pretty much annoying); if not possible I will see how to participate directly in patching the file, but I'm not used to big projects participations...

According to the iCal RFC, it should already accept DURATION as it is the default value type, so it really is a Calendar bug: https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.6.3

Here's a proper patch file, so it can be easily merged.

IIRC evaluation of && in C is lazy, so, as a duration is not a datetime, will the second clause ever be tested?

Would be great though, if that is where the fix lies :)

Well as it's chaining inequality comparisons (to catch wrong types), it will work; if you follow the link to the full source code of this file, this is how the other elements are tested.
I'm not sure this is the most optimal way to test it (maybe it is, I don't know of the preprocessor will optimize it, and my knowledge of this kind of stuff is very far), but I chose to keep the code rules already present in the file :)
(And yes, it woulf be really great if an active developer could see this and validate it for the next release...)

(In reply to OpenJD from comment #39)

Well as it's chaining inequality comparisons (to catch wrong types), it will work; if you follow the link to the full source code of this file, this is how the other elements are tested.
I'm not sure this is the most optimal way to test it (maybe it is, I don't know of the preprocessor will optimize it, and my knowledge of this kind of stuff is very far), but I chose to keep the code rules already present in the file :)
(And yes, it woulf be really great if an active developer could see this and validate it for the next release...)

Geoff, is that a patch you could review and help uplift into Thunderbird, as you recently worked on Calendar?

Flags: needinfo?(geoff)

I sure would. I hate this error message too, but I've never had the time to figure it out.

FWIW, X- properties are allowed in the specification and should be ignored by implementations that don't understand them.

Flags: needinfo?(geoff)
Attachment #9227653 - Flags: review+

That's for your patch OpenJD, I've approved it and will have it checked in.

Assignee: nobody → josselin.dulac
Status: NEW → ASSIGNED

Thank you very much!

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/15eefd39d789
In libical, accept DURATION as a valid type for TRIGGER properties. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch

Comment on attachment 9227653 [details] [diff] [review]
1560151-trigger-duration.diff

[Approval Request Comment]
Regression caused by (bug #): Bug 1555646
User impact if declined: Calendar item parsing fails to read a property, adds an error message to the item, other clients complain about it
Testing completed (on c-c, etc.): Just landed
Risk to taking this patch (and alternatives if risky): I don't see any risk, it's a correctness patch

Attachment #9227653 - Flags: approval-comm-esr78?
Attachment #9227653 - Flags: approval-comm-beta?

(In reply to Geoff Lankow (:darktrojan) from comment #45)

Comment on attachment 9227653 [details] [diff] [review]
1560151-trigger-duration.diff

OMG! That would be so awesome! I'm very curious, if it will fix it! Thanks a lot!

(In reply to kalle from comment #46)

(In reply to Geoff Lankow (:darktrojan) from comment #45)

Comment on attachment 9227653 [details] [diff] [review]
1560151-trigger-duration.diff

OMG! That would be so awesome! I'm very curious, if it will fix it! Thanks a lot!

<joke>AND not introduce a new bug at the same time!</joke>

Thanks!

(In reply to Steve B. from comment #47)

<joke>AND not introduce a new bug at the same time!</joke>

Thanks!

I hope too, it would be sad for my 1st patch :D

Time for your first parachute jump...

Comment on attachment 9227653 [details] [diff] [review]
1560151-trigger-duration.diff

[Triage Comment]
Approved for beta

Attachment #9227653 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9227653 [details] [diff] [review]
1560151-trigger-duration.diff

[Triage Comment]
Approved for esr78

Attachment #9227653 - Flags: approval-comm-esr78? → approval-comm-esr78+

UnFuckingbelieable... :) Just updated and I have no error and no popup when syncing the "Birthdays from contacts"-calendar from Nextcloud. Now wating for the next reminder, when a birthday. :) When its closeable without any trouble, everythings perfect. Thanks a lot to everone involved, especially @OpenID!

Thank you @kalle and thank you the whole team (review, commits, and on). This little change will also change my daily use of Thunderbird ^^
(And it was really nothing ^^)

I'm worried the fix is not enough. I'm still having errors both in version 78.12.0 and 91.0b1, Linux & Windows:

CalDAV: Unexpected status modifying item to MyCalendar: 405
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20210630T085146Z
LAST-MODIFIED:20210717T090432Z
DTSTAMP:20210717T090432Z
UID:9c70b2b8-3019-471a-9a86-4e94c11b600b
SUMMARY:My event
X-MOZ-LASTACK:20210717T090432Z
DTSTART;VALUE=DATE:20210717
DTEND;VALUE=DATE:20210719
TRANSP:TRANSPARENT
X-MOZ-GENERATION:1
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Description par défaut Mozilla
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parame ter with an illegal type for property: VALUE=DURATION
END:VALARM
END:VEVENT
END:VCALENDAR

So maybe my patch is not enough? Any other returns?

I' am worried about that too. :/ I have also still issues. But with different error messages. I'l document it during the day and post it here later!

Now I did some more testing...
Because I have these problems only with a Nextcloud "Birthdays from contacts"-calendar, I setupped a new Nextcloud instance with only a few contacts with a birthday in it. This calendar is in Nextcloud created automatically and write protected for all users. The events in this calendar have a reminder, that's timed for midnight and are for the whole day. For comparing I created also a "normal" calendar, with and without reminder settings in the events, with special durations and for the whole day. So the normal Calendar works like it should. the reminder pops up and is closeable with the close button in the window and doesn't throw an error. The birthday calendar reminders are only closable over the X in the titlebar an throw the error. The "illegal type for property: VALUE=DURATION"-error doesn't show up in no case anymore. So I think its for me another problem now and your patch does what it should.

Lightning: CalDAV: Unexpected status modifying item to geburtstag aidlec: 404
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20210718T071933Z
LAST-MODIFIED:20210718T071947Z
DTSTAMP:20210718T071947Z
UID:6f28a0d9-f539-4181-841a-05d7280a61a2
SUMMARY:🎂 Jul Birthday (1976)
RRULE:FREQ=YEARLY
X-MOZ-LASTACK:20210718T071947Z
DTSTART;VALUE=DATE:19760717
DTEND;VALUE=DATE:19760718
TRANSP:TRANSPARENT
X-NEXTCLOUD-BC-FIELD-TYPE:BDAY
X-NEXTCLOUD-BC-UNKNOWN-YEAR:0
X-NEXTCLOUD-BC-YEAR:1976
X-MOZ-SNOOZE-TIME-1626480000000000:20210718T072447Z
X-MOZ-GENERATION:1
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:PT0S
DESCRIPTION:🎂 Jul Birthday (1976)
END:VALARM
END:VEVENT
END:VCALENDAR

I'll do some more testing also with my productive data, which has around 900 contacts with 300 birthdays, an about 5 calendars with plenty of events. :) so finally it looks like the birthday events are although the error shown in the calendar, whats for me definitely is an improvement. ;)

In my case the error is now: "item.startDate is null".
If someone is following here with the same problems with nextcloud, here I opened a new bug 1721085

I think you'll find the error message was added to events before the fix and is still there because there's no mechanism to remove it.

True, it seems that removing the agenda and adding it again solves the problem.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: