Issue in upgrade from 17.1 to 19.1

vishakha 2020-07-10 16:18:07 UTC #4

Can someone help me if there was anything wrong with the composer update method for my archive installation. All other updates look okay, the db update was successful.

Why is the access log update query not having any arguments when the user is already existing and login is successful ?

Is this the case that version 19.1 (version 19.1.20200318) can only be upgraded via docker

StefanU 2020-07-10 17:34:30 UTC #5

Hi vishakha.

I don’t understand what you’re doing. What does an archive install have to do with Docker?

Stefan

RalfBecker 2020-07-10 17:42:50 UTC #6

Using composer is generally ok, our containers are also build with composer.

Question is, did you run the necessary database migrations?

If not, go to setup (https://your.domain/egroupware/setup/ upper login) and run them.

Ralf

vishakha 2020-07-10 17:43:00 UTC #7

Hi Stefan,

I’m under the process of upgrading my version to 19.1 from 17.1.
My current installation type is archive and the upgrade method was through composer.
I posted the errors I’m receiving in the first message in the post. I can’t seem to figure out the cause of the access log update query failure. I even removed my custom application to see if anything changes.

Could you guide me if you notice anything here. The exact version is 19.1.20200318.
This is something I had been trying since so long, any help would be appreciated

I was just curious about docker updates and had questions if that’s possible in my case.

vishakha 2020-07-10 17:52:47 UTC #8

Yeah I ran them, they seemed to have executed well
I can see in the setup that db updates were successful

StefanU 2020-07-10 17:54:08 UTC #9

Read this:

and then decide if the EGroupware standard docker installation is right for you.

Maybe you can install another system and try it out first. I once wrote something about my installation:

There is a reason why we install EGroupware as standard with Docker. Some things can only be realized if we separate EGroupware and the integrated systems (Collabora Online, Rocket.Chat, Guacamole and what ever…) as containers. Among a few other reasons…

Stefan

RalfBecker 2020-07-10 18:05:04 UTC #10

Docker installation allows you to run / integrate your own custom apps, just clone them into /usr/share/egroupware on the host and the starting container will copy them into the container.

There has been no schema change on egw_access_log table between 17.1 and 19.1.

Maybe the problem is caused by an “old” session, created under 17.1 now have trouble with the 19.1 sources.

Ralf

vishakha 2020-07-10 18:09:26 UTC #11

So should I remove the data from access log table to start a new session record ?
because the issue is the arguments only are not being passed in the query, usually the missing arguments came from missing schema structure, so I’m confused a bit

vishakha 2020-07-10 19:59:58 UTC #12

Okay I tried truncating the access log table, I still have the issue with update query as I check the logs and additionally see the following in my console.

Ajax request to https://project/egroupware/json.php?menuaction=rocketch…_exec.template.rocketchat.EGroupware%5CRocketchat%5CUi.index failed: parsererror 200 OK
Ajax request to https://project/egroupware/json.php?menuaction=status.j…ork.ajax_exec.template.status.EGroupware%5CStatus%5CUi.index failed: parsererror 200 OK
Ajax request to https://project/egroupware/json.php?menuaction=infolog.jdots_framework.ajax_exec.template.infolog.infolog_ui.index failed: parsererror 200 OK
Ajax request to https://project/egroupware/json.php?menuaction=filemana…ramework.ajax_exec.template.filemanager.filemanager_ui.index failed: parsererror 200 OK

vishakha 2020-07-13 14:14:29 UTC #13

Do you have any solution in mind that I can try in this case.

RalfBecker 2020-07-13 14:30:17 UTC #14

Check if the error still happens after manually calling https://example.org/egroupware/logout.php and login in again.

Ralf

vishakha 2020-07-13 14:36:30 UTC #15

Yes it still exists

2020-07-13 09:34:57: (mod_fastcgi.c.421) FastCGI-stderr: Database error (EGroupware\Api\Db\Exception\InvalidSql): Invalid SQL: UPDATE egw_access_log SET WHERE

J_Roeleveld 2020-07-13 18:50:57 UTC #16

I see a red X in step 4, did you manage to clear that?

vishakha 2020-07-13 19:04:07 UTC #17

This is because I removed my custom application folder from egroupware directory, thinking that this might be causing issues.
Even if I put the custom application directory back in, it still gives the error I’ve been facing. The setup config will be fixed thereafter.

RalfBecker 2020-07-14 07:02:27 UTC #18

Only explanation I have for that mangled SQL is that our main schema file (api/setup/tables_current.inc.php) is somehow broken. Are you sure not having any git conflicts?

I suggest the following:

get a EGroupware backup from your 17.1 installation
make a regular 19.1 or 20.1 installation on one of our supported Linux distros
restore your backup

Ralf

vishakha 2020-07-14 17:16:59 UTC #19

Okay thanks for your advice

I started the upgrade again from 17.1 and have 20.1 version now, working without the access log issues.

I have now the following errors

Call to undefined method EGroupware\Api\Session::appsession().

Please advice how to fix this

Also since phpgwapi has now been removed, I was using the following code in my custom application which now is deprecated. How do I fix this

$this->jscal = createObject('phpgwapi.jscalendar');

RalfBecker 2020-07-14 20:43:10 UTC #21

github.com

EGroupware/egroupware/blob/master/doc/fix_api.php

#!/usr/bin/env php
<?php
/**
 * EGroupware - check namespace usage in converted code
 *
 * @link http://www.egroupware.org
 * @license http://opensource.org/licenses/gpl-license.php GPL - GNU General Public License
 * @author Ralf Becker <rb@stylite.de>
 * @copyright 2016 by Ralf Becker <rb@stylite.de>
 * @version $Id$
 */

if (php_sapi_name() !== 'cli')	// security precaution: forbit calling as web-page
{
	die('<h1>fix_api.php must NOT be called as web-page --> exiting !!!</h1>');
}

// raw replacements
$add_use_api = array(
	"#use EGroupware\\\\Api;\n#" => '',	// remove evtl. use EGroupware\Api, as we add it again below

This file has been truncated. show original

vishakha 2020-07-16 20:46:42 UTC #22

Thanks for sharing this file Ralf. This is much helpful

What I’m unable to find is the jscalendar, I have used it in my date fields and instantiated like this

This was used before,

$this->jscal = createObject('phpgwapi.jscalendar');
$this->jscal->input('lastdateworked', date('m/d/Y'))

How do I access all the js ibraries that were used in phpgwapi

RalfBecker 2020-07-17 07:24:00 UTC #23

jscalendar is such an ancient library, it is simply no longer available in our current API.

Our current API and eTemplate2 uses jQuery DatePicker:

github.com

EGroupware/egroupware/blob/master/api/js/jsapi/egw_calendar.js#L241


			{
				trans = egw().lang(trans);
			}
			regional[i] = trans;
		}
		_wnd.jQuery.timepicker.setDefaults(regional);
	};


	return {
		/**
		 * setup a calendar / date-selection
		 *
		 * @member of egw
		 * @param _input
		 * @param _time
		 * @param _callback
		 * @param _context
		 * @returns
		 */
		calendar: function(_input, _time, _callback, _context)
		{

If logged into EGroupware you can eg. call it via the JavaScript console of your browser:

egw.calendar(jQuery('<input value="2020-07-17"/>').prependTo('div.egw_fw_content_browser_div'), false, function(v){console.log(v);});

Ralf

vishakha 2020-07-17 16:49:20 UTC #24

Is there a way to instantiate this in PHP, since the script is already loaded I should be able to use it anywhere.
It returns the calendar object in the browser console.
I have a custom JS file in my application, when I do console.log(egw.calendar), it gives me an error saying egw is not defined.

Do you have any documentation on how to instantiate this calendar to be able to use in in a custom date field of your custom application