Issue in upgrade from 17.1 to 19.1

RalfBecker 2020-07-30 06:43:54 UTC #42

Only ideas I have:

you used an old session, from before you removed the deprecated apps
you did not restart our container, which copies the deprecated code inside

Ralf

vishakha 2020-07-30 13:44:23 UTC #43

I’m not using Docker.
Can I clear cache from egroupware and restart my lighttpd server

vishakha 2020-07-30 13:59:20 UTC #44

After doing some debugging, I found that not all update queries fail for the access log.It fails at some point when accessing the default app page. I set the default app page to filemanager and this is the sequence of logs

UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/categories.php’,lo=NULL WHERE sessionid=4289950

UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/config.php’,lo=NULL WHERE sessionid=4289950

UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/images.php’,lo=NULL WHERE sessionid=4289950

UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/user.php’,lo=NULL WHERE sessionid=4289950

Instance=default, User=vish, Request=POST https://project.com/egroupware/json.php?menuaction=filemanager.jdots_framework.ajax

When this request is issued, the query fails, the table definition array returns empty and thus no arguments in the query are passed

UPDATE egw_access_log SET WHERE

UPDATE egw_access_log SET session_dla=1596116843,session_action=’/api/lang.php’,lo=NULL WHERE sessionid=4289950

UPDATE egw_access_log SET session_dla=1596116877,session_action=’/index.php’,lo=NULL WHERE sessionid=4289950

An error happened! (EGroupware\Api\Exception\AssertionFailed): CreateObject() file /home/www.tempstop.com/public_html/egroupware/api/inc/class…in

Not sure what the error corresponds here

UPDATE egw_access_log SET session_dla=1596116877,session_action=’/index.php’,lo=NULL WHERE sessionid=4289950

Instance=default, User=vish, Request=POST https://project.com/egroupware/json.php?menuaction=filemanager.jdots_framework.ajax>

UPDATE egw_access_log SET WHERE.

Please advice. I cleared the cache from the Clear Cache and register hooks option in the setup and even restarted the server. Also I’m using an incognito window

vishakha 2020-07-30 15:09:13 UTC #45

I was removing the deprecated code in my custom application on my local server. After doing the upgrade on production I moved the modified class files of the application. I have also restarted the upgrade several times to get rid of the errors, but nothing changes.
I’m doing through composer with the following steps

composer create-project --prefer-source --keep-vcs egroupware/egroupware
Copy the custom application in egroupware folder
Copy the header file in egroupware
Run the db migrations to upgrade

I was using 17.1 version before and with the composer command I got upgraded to the latest version 20.1 which turned out well on my local server which was used for testing but not on production

vishakha 2020-07-30 19:52:22 UTC #46

This is what I see on my screen, please advise how to solve this

RalfBecker 2020-07-30 20:38:24 UTC #47

No idea what to do apart from starting to debug your installation

vishakha 2020-07-30 20:42:27 UTC #48

Is there a way to comment updating the access log update queries ?

vishakha 2020-07-30 20:42:55 UTC #49

It’s really strange how it’s failing on application index page load

RalfBecker 2020-07-30 20:56:51 UTC #50

I don’t understand the question.

Do you want to comment out the access log update?

The code is the following:

github.com

EGroupware/egroupware/blob/master/api/src/Session.php#L1886-L1893


			$GLOBALS['egw']->db->update(self::ACCESS_LOG_TABLE,array(
				'session_dla' => time(),
				'session_action' => $this->action,
			) + ($this->action === '/logout.php' ? array() : array(
				'lo' => null,	// just in case it was (automatic) timed out before
			)),array(
				'sessionid' => $this->sessionid_access_log,
			),__LINE__,__FILE__);

The top 2 arrays are the SET and the lower one is the WHERE. How they can be empty is a mystery of your installation, unless you call set_app() on the global DB object, that would produce something like that.

Ralf

vishakha 2020-07-30 20:59:29 UTC #51

The arguments are only empty when loading the default application page, rest all update queries run perfectly as shown in my previous messages containing the logs.