Workflow in trunk

Nathan_Gray-2 2008-08-26 15:08:31 UTC #1

I’m having some issues with workflow in trunk. I know there’s only a
few of us who use it, but I need some help.

Warning: mkdir() [function.mkdir]: Permission denied in /var/www/
perpdevel/workflow/inc/engine/config.egw.inc.php on line 48

Fatal error: Call to a member function translate() on a non-object in /
var/www/perpdevel/phpgwapi/inc/common_functions.inc.php on line 1293

If you have workflow installed, this will break everything that calls
it (Admin, Preferences, etc). This is the first error encountered,
but it goes away if I define SEP again in workflow/inc/engine/
config.egw.inc.php. Turns out SEP was used somewhere. PHP docs say
that / will work everywhere, so it should be safe to go through and
replace all the SEPs in workflow.

It comes back
I think there’s something missing with the session. In (1.), the
workflow directory gets defined as:
/var/www/erp_filesSEPworkflow (or /var/www/erp_files/workflow after I
define SEP).
The first part comes from $GLOBALS[‘egw_info’][‘server’][‘files_dir’].
In some cases (tough to narrow down, seems to be a little erratic),
the workflow directory gets defined as:
/workflow
And $GLOBALS[‘egw_info’][‘server’][‘files_dir’] is not set. Neither
is $GLOBALS[‘egw’].

Where did $GLOBALS[‘egw’] go, and how to get it back?

Nathan Gray
nathan at goarctic dot com

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Ralf_Becker_6 2008-08-29 12:07:09 UTC #2

Hi Nathan,

I wild guess: Workflow never worked (for whatever reason) with the
session restore, which is now on unconditionally.

That’s only a quess, I have had a workflow installation …

Ralf

Nathan Gray schrieb:

I’m having some issues with workflow in trunk. I know there’s only a
few of us who use it, but I need some help.

Warning: mkdir() [function.mkdir]: Permission denied in /var/www/
perpdevel/workflow/inc/engine/config.egw.inc.php on line 48

Fatal error: Call to a member function translate() on a non-object in /
var/www/perpdevel/phpgwapi/inc/common_functions.inc.php on line 1293

If you have workflow installed, this will break everything that calls
it (Admin, Preferences, etc). This is the first error encountered,
but it goes away if I define SEP again in workflow/inc/engine/
config.egw.inc.php. Turns out SEP was used somewhere. PHP docs say
that / will work everywhere, so it should be safe to go through and
replace all the SEPs in workflow.

It comes back
I think there’s something missing with the session. In (1.), the
workflow directory gets defined as:
/var/www/erp_filesSEPworkflow (or /var/www/erp_files/workflow after I
define SEP).
The first part comes from $GLOBALS[‘egw_info’][‘server’][‘files_dir’].
In some cases (tough to narrow down, seems to be a little erratic),
the workflow directory gets defined as:
/workflow
And $GLOBALS[‘egw_info’][‘server’][‘files_dir’] is not set. Neither
is $GLOBALS[‘egw’].

Where did $GLOBALS[‘egw’] go, and how to get it back?

Nathan Gray
nathan at goarctic dot com

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Nathan_Gray-2 2008-09-02 14:35:13 UTC #3

Hi Nathan,

I wild guess: Workflow never worked (for whatever reason) with the
session restore, which is now on unconditionally.

That’s only a quess, I have had a workflow installation …

Hi Ralf, how’s the leg?

I guess I need to know how to work with the session restore, because
there’s some things that seem to be acting strangely now.

I’m getting other reports of missing config::db (http://www.nabble.com/Invoicing-Issues-tp19232378p19232378.html
) which I suspect are related, config::init_db() pulls from
$GLOBALS[‘egw’]->db.

Nathan Gray
nathan at goarctic dot com

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Ralf_Becker_6 2008-09-03 08:20:53 UTC #4

Hi Nathan,

Nathan Gray schrieb:

Hi Nathan,

I wild guess: Workflow never worked (for whatever reason) with the
session restore, which is now on unconditionally.

That’s only a quess, I have had a workflow installation …

Hi Ralf, how’s the leg?

Slowly getting better.

I can only work using a deck chair and my laptop …

I guess I need to know how to work with the session restore, because
there’s some things that seem to be acting strangely now.

Regular eGW applications should work with or without session restore.
The restore is done in the api: Instead of creating the $GLOBALS[egw]
object and $GLOBALS[egw_info] array anew on each request it will be
stored in the session and restored from there.
Open tcp connections (database or LDAP) need a special treatment to
reopen the connection after the restore (usually via a __wakeup() method
in the class holding the connection).

eGW apps are usually not affected as the egw object is stored right
after the header include, before any application specific code or
classes should be loaded. Meaning all application specific code and
classes is NOT restored from the session, but created on each request.

I’m getting other reports of missing config::db (http://www.nabble.com/Invoicing-Issues-tp19232378p19232378.html
) which I suspect are related, config::init_db() pulls from
$GLOBALS[‘egw’]->db.

I would try dump self::$db, when you get the error to see if it’s set
and to what.

I doubt a bit this problem is releated to the session restore.

Ralf

Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Nathan_Gray-2 2008-09-03 14:09:00 UTC #5

…

I’m getting other reports of missing config::db (http://www.nabble.com/Invoicing-Issues-tp19232378p19232378.html
) which I suspect are related, config::init_db() pulls from
$GLOBALS[‘egw’]->db.

I would try dump self::$db, when you get the error to see if it’s set
and to what.

Ok, I’ll see what’s up in there. Thanks.

Nathan Gray
nathan at goarctic dot com

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers