Import ics: DB error concerning column truncation, how to report that issue?

Hi, I’m about to migrate from Owncloud to Nextcloud, so I’m new here; please bear with me.

My brand new installation (18.0.1) uses PostgreSQL. On importing an ICS file, exported from Owncloud, I get error messages as follows:

An exception occurred while executing ‘INSERT INTO “oc_calendarobjects_props” (“calendarid”, “calendartype”, “objectid”, “name”, “parameter”, “value”) VALUES(?, ?, ?, ?, ?, ?)’ with params [6, 0, 1045, “DESCRIPTION”, null, “Aus der Ank\u00fcndigung:\nTord Gustavsen ist mit Sicherheit Norwegens herausragendster Jazzpianist. Er verbindet wie kein anderer die Geschichte des Jazz mit tiefen Wurzeln im Gospel und Blues mit den f\u00fcr uns so typischen Kl\u00e4ngen seiner norwegischen Heimat, d”]: SQLSTATE[22001]: String data, right truncated: 7 ERROR: value too long for type character varying(255)

The root cause is clear: oc_calendarobjects_props.value is varchar(255) and descriptions shall be stored in it, many calendar descriptions may be longer. After enlarging this column, the import succeeded without any error.

Interestingly, even with the error message, the calendar event was successfully imported and I could export it completely without any error. Thus, storing the description in oc_calendarobjects_props seems not to be a crucial functionality. It is stored somewhere else. (Incidentially, I tried to find out where it is stored and I didn’t succeed. I neither found this description in the DB, nor in any file in the data area. Anyhow, I digress.)

The error message about the DB exception and the truncation is very irritating; especially since the actual import seems to work. In addition, the column type in this table should (IMNSHO, obviously) be changed to accomodate longer values.

So, eventually, my question:
What is the proper way to report such (minor) issues?
Here in the forum, on some issue tracker (where)?

If it is on an issue tracker, I would appreciate experience reports if the development team reacts to such minor issues reports, when no code patches are attached. For me, it works now; I’ll only invest the time to create a proper problem ticket with demo data and logs, if there’s a reasonable chance that somebody reacts to it.


Yeah, this table is only used for building search around calendar contacts - even though that’s not used right now, so that’s not a big deal, but the exception should be handled properly.

Feel free to open an issue on Github about this: