Error using tracker canned response after upgrade from epl 17

[pldunda]

I have moved our data from epl-17.1.20190808 to docker 21.1.20230210
epl-17 was using postgres 13.9-0+deb11u1 amd64
docker 21.1 is on external mariadb 1:10.5.18-0+deb11u1 amd64 ( same VM as above postgres )

The action of adding a comment and selecting a canned response results in the following error popup :-
“An error happened!
Cannot access offset of type string on string
/usr/share/egroupware/tracker/inc/class.tracker_bo.inc.php (1497)”

Within the Admin tracker configuration I can see the migrated canned responses. Here is one example :-

"Please check and if all is OK set to 100% and close the ticket

Actions taken
---------------------"

Advise is greatly appreciated.

Thanks, Paul.

[RalfBecker]

Hi Paul,

in that line we iterate over all tracker categories and try to find the one with type==“response” and the given category id.

I can only assume that (maybe due to the migration) one of the cat_data columns contains a wrongly serialized of maybe cut off data. The data of the column should either be PHP or JSON serialized.

If you can’t find it, you could alternativ find the canned response in Tracker admin, change it slightly and store it again (you can change it back after).

Ralf

[pldunda]

Thank you for you prompt reply.
We have been using eGrouopware since v14.2 and this data has come with us from then.
I have modified the data as recommended but without success. The error pop-up remians the same. ( I added an ‘x’ to the string) I do note however that when I query the raw data the cat_description is ‘tracker-’

| 94 | 94 | 0 | 0 | 0 | public | tracker | General - Check and close | tracker- | {“type”:“response”,“response”:“Please check and if all is OK set to 100% and close the ticket\n\nActions taken\n---------------------”} | 1552358634 |

| 94 | 94 | 0 | 0 | 0 | public | tracker | General - Check and close | tracker- | {“type”:“response”,“response”:“Please check and if all is OK set to 100% and close the ticket\n\nActions taken\n---------------------\nx”} | 1676672843 |

I am an open source supporter and my core is IT integration of the best open source systems I come across. https://obt.net.au
I must thank you for your excellent system and organisation.

Thank you.

[RalfBecker]

Hmm, looks all ok to me

We have now two possibilities:

a) you install an editor in the container and add some debug code helping to figure out what your problem is

b) buy 30min Community Support AND send me via a secure channel your database dump. I’ll install it on my development machine and run it with a debugger, finding and fixing the problem in our code or you data, whichever makes more sense.

Ralf

[pldunda]

I have found that one row was causing the issue. Deleting the canned response has resolved the issue. I have re-created the response with the same text and all seems OK. I could not see what was causing the problem within the data. I have kept the offending data for further analysis if needed.
Thanks very much for your help and attention.

[RalfBecker]

Can you share the row with us, maybe we can prevent something like this from happening in future.

Ralf

[pldunda]

Hi Ralf. Sorry for the delay.

Please find the data dumped from the postgres based egw 17.1 instance along with a mysql dump of the egw_categories table from the 21.1 version exhibiting the error in question.

I have the complete schema in the 17.1 backup but, left only the egw_categories.

The restore of the 17.1 data into the 21.1 environment does report an error but, it does not seem to me to relate to the tracker response problem

"EGroupware API version 21.1.001 found. EGroupware configuration file (header.inc.php) version 1.29 exists and is up to date EGroupware domain/instance se(mysqli): Start updating the database … 85800 history-records converted in 1.6 minutes to diff with a total of 424.5 MB saved /usr/share/egroupware/api/src/Vfs/Sqlfs/StreamWrapper.php (759) An error happened! SQLSTATE[HY000]: General error: 1364 Field ‘fs_active’ doesn’t have a default value"

[pldunda]

Further investigation may indicate that the rows brought across asking to set the the resolution to 100% complete could be the culprits.

[RalfBecker]

An error happened! SQLSTATE[HY000]: General error: 1364 Field ‘fs_active’ doesn’t have a default value

Was that from PostgreSQL or MariaDB?

Anyway egw_sqlfs.fs_active should have a default value of true (Postgres: t, MariaDB/MySQL: 1)!

Ralf

[pldunda]

That was the error message restoring the postgres 17.1007 backup into the 21.1 mariadb instance.

[RalfBecker]

Anyway egw_sqlfs.fs_active should have a default value of true (Postgres: t, MariaDB/MySQL: 1)!

This is what you should set, to fix that error, otherwise you will have Problems later!

Ralf