Workflow new features

Old eGW-developers
1

Hello Regis,

We started coding a process with Workflow and we are in need of some new features:

  • Access to a database outside eGroupware
  • Hide $Globals and $db from designers
  • More than one template per activity
  • A path to store images used in processes
  • Integration with an external Php editor
  • A pick user window, at roles mapping, to handle a large list of users
    (thousands). In our case we’ve Ldap with users grouped by OU
  • An option to Smarty templates (already made by Rodrigo Lira, and waiting for your tests and commit)

We’d like to discuss these things in more details and, if you like, work in one or more of them.

Regards,

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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

2

Mauricio Luiz Viani a écrit :

Hello Regis,

We started coding a process with Workflow and we are in need of some
new features:

Sure we need :slight_smile:

  • Access to a database outside eGroupware

You can do in activities all the things you can do in PHP, no limit,
that means activities code should only be accessible by administrators,
but you can connect where you want. Maybe you need it as a “designer
form to connect somewhere” but it’s another job.

  • Hide $Globals and $db from designers

This is the way I’d like to take for the next versions, effectively

  • More than one template per activity

This is possible already if you code your templates and code directly in
the dierectories where they are stored (via ssh for example) and not via
the web interface. but having something more usable in the web interface
is one of the thing to do.

  • A path to store images used in processes

Actually it is workflow/template/default/images/ we could think about
something better, effectively

  • Integration with an external Php editor

You can, activities’s code are stored in real php files, are you talking
about a web editor?

  • A pick user window, at roles mapping, to handle a large list of
    users (thousands). In our case we’ve Ldap with users grouped by OU

Yes, that’s right, We actually use a deprecated way to list user at this
place, this could be noted as a bug (could you please do the bug report :slight_smile:

  • An option to Smarty templates (already made by Rodrigo Lira, and
    waiting for your tests and commit)

Effectively, more of this coming after the stable release

We’d like to discuss these things in more details and, if you like,
work in one or more of them.

Everybody is really welcome to work/discuss/collaborate, of course.

Régis Leroy,

Regards,
------------------------------------------------------- This SF.net
email is sponsored by: Splunk Inc. Do you grep through log files for
problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________ eGroupWare-developers
mailing list eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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

3

Hi Regis,

For us, the most important items, at this moment, are first and second
(maybe to other workflow developers too, I don’t know). In our case we
need to retrieve and store data to a external database, and of course,
we can code this second access inside an activity (maybe at shared
code). But what about making a new workflow preference to store the
connection parameters (host, db, etc) and deliver a ready Adodb object
to the developer? If you think its fine, we can try do this.

Another thing is that we’ll have to delegate programming to other
people and we wouldn’t like to run the risk of a crash by
inappropriate use of $db

egroupware-developers@lists.sourceforge.net escreveu:

Mauricio Luiz Viani a écrit :

Hello Regis,

We started coding a process with Workflow and we are in need of some

new features:

Sure we need :slight_smile:

  • Access to a database outside eGroupware

You can do in activities all the things you can do in PHP, no limit,

that means activities code should only be accessible by administrators,

but you can connect where you want. Maybe you need it as a "designer

form to connect somewhere" but it’s another job.

  • Hide $Globals and $db from designers

This is the way I’d like to take for the next versions, effectively

  • More than one template per activity

This is possible already if you code your templates and code directly in

the dierectories where they are stored (via ssh for example) and not via

the web interface. but having something more usable in the web interface

is one of the thing to do.

  • A path to store images used in processes

Actually it is workflow/template/default/images/ we could think about

something better, effectively

  • Integration with an external Php editor

You can, activities’s code are stored in real php files, are you talking

about a web editor?

  • A pick user window, at roles mapping, to handle a large list of

users (thousands). In our case we’ve Ldap with users grouped by OU

Yes, that’s right, We actually use a deprecated way to list user at this

place, this could be noted as a bug (could you please do the bug report :slight_smile:

  • An option to Smarty templates (already made by Rodrigo Lira, and

waiting for your tests and commit)

Effectively, more of this coming after the stable release

We’d like to discuss these things in more details and, if you like,

work in one or more of them.

Everybody is really welcome to work/discuss/collaborate, of course.

Régis Leroy,

Regards,

------------------------------------------------------- This SF.net

email is sponsored by: Splunk Inc. Do you grep through log files for

problems? Stop! Download the new AJAX search engine that makes

searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!

http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

_______________________________________________ eGroupWare-developers

mailing list eGroupWare-developers@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/egroupware-developers

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files

for problems? Stop! Download the new AJAX search engine that makes

searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!

http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

eGroupWare-developers mailing list

eGroupWare-developers@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/egroupware-developers

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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

4

At first it should be possible (and it seems quite easy) to create a db
connection specifically for an ADODB object usable by the templates
(maybe a db agent, handling persitence if possible).
Actually the AdoDb object is the AdoDB owned by the Runtime object (and
derivated from egw’s ADOdb object). This Runtime object use it for his
own purpose, we would need to:

  • set all calls to this objects in other objects implemented by the
    Runtime object

  • unset al theses objects before running the activity code

  • … well, no, I cannot see a fine way to unset all the GLOBALS from
    egroupware… I don’t think it’s possible to prohibit completly the use
    of egroupware’s connection.

  • The activity template is PHP code runned on the server, there’s no way
    to have it runned in a secure way. We can break a LOT of things with
    running PHP code on the server side, like files on the system - even if
    you limit the avaibles directories, all PHP functions aren’t safe, even
    with safe_mode (well, maybe you could list all unsafe functions and
    prohibit them). And this workflow is designed to let the process
    developers write PHP code for the server.
    The only way we have to secure the activity code is to avoid complety
    code edition by process developers (an acl to add, as we want them to
    access the rest of the process edition) and hide it under pre-coded
    features, something that is “in the road” in fact. But even if we are
    smart enought to “pre-code” a lot of things and add a lot of parameters
    this will make theses processes less powerfull (but that’s what we want :-).

It will be PHP code + automatic forms or automatic forms without PHP
code. And the second way is the only way to delegate it securely.
The only other way is adding a special basic language with an
interpreter and hoping it will be a good one, and this seems to be a
very hard way, not the Galaxia goal actually.

Régis Leroy,

Mauricio Luiz Viani wrote:

Hi Regis,

For us, the most important items, at this moment, are first and second (maybe to
other workflow developers too, I don’t know). In our case we need to retrieve
and store data to a external database, and of course, we can code this second
access inside an activity (maybe at shared code). But what about making a new
workflow preference to store the connection parameters (host, db, etc) and
deliver a ready Adodb object to the developer? If you think its fine, we can try
do this.

Another thing is that we’ll have to delegate programming to other people and we
wouldn’t like to run the risk of a crash by inappropriate use of $db

egroupware-developers@lists.sourceforge.net escreveu:

Mauricio Luiz Viani a écrit :

> Hello Regis,
>
> We started coding a process with Workflow and we are in need of some
> new features:
>

Sure we need :slight_smile:

> - Access to a database outside eGroupware

You can do in activities all the things you can do in PHP, no limit,
that means activities code should only be accessible by administrators,
but you can connect where you want. Maybe you need it as a “designer
form to connect somewhere” but it’s another job.

> - Hide $Globals and $db from designers

This is the way I’d like to take for the next versions, effectively

> - More than one template per activity

This is possible already if you code your templates and code directly in
the dierectories where they are stored (via ssh for example) and not via
the web interface. but having something more usable in the web interface
is one of the thing to do.

> - A path to store images used in processes

Actually it is workflow/template/default/images/ we could think about
something better, effectively

> - Integration with an external Php editor

You can, activities’s code are stored in real php files, are you talking
about a web editor?

> - A pick user window, at roles mapping, to handle a large list of
> users (thousands). In our case we've Ldap with users grouped by OU

Yes, that’s right, We actually use a deprecated way to list user at this
place, this could be noted as a bug (could you please do the bug report :slight_smile:

> - An option to Smarty templates (already made by Rodrigo Lira, and
> waiting for your tests and commit)
>

Effectively, more of this coming after the stable release

> We'd like to discuss these things in more details and, if you like,
> work in one or more of them.

Everybody is really welcome to work/discuss/collaborate, of course.

Régis Leroy,

>
> Regards,
> ------------------------------------------------------- This SF.net
> email is sponsored by: Splunk Inc. Do you grep through log files for
> problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________ eGroupWare-developers
> mailing list eGroupWare-developers@lists.sourceforge.net <#>
> https://lists.sourceforge.net/lists/listinfo/egroupware-developers

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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

------------------------------------------------------- This SF.net email is
sponsored by: Splunk Inc. Do you grep through log files for problems? Stop!
Download the new AJAX search engine that makes searching your log files as easy
as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________ eGroupWare-developers mailing
list eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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

5

Hello Régis,

Thank you for your answer. I read it carefully and a agree with things
you said. I think that what is possible to do, at this moment, in our
case, is prohibit process developers from using Globals by filtering
activity code. I don’t know how to do this yet, but I’ll dig into code
and try to find a way. Of course this will make processes less
powerful, but I hope it will prevent processes developers from making
inappropriate access to egw database.

Following your directions about an external db connection, I’ll try to
develop a new agent to do this (similar to smtp agent already
available). If I had success, I’ll send you the code.

Regards,

Viani.

egroupware-developers@lists.sourceforge.net escreveu:

At first it should be possible (and it seems quite easy) to create a db

connection specifically for an ADODB object usable by the templates

(maybe a db agent, handling persitence if possible).

Actually the AdoDb object is the AdoDB owned by the Runtime object (and

derivated from egw’s ADOdb object). This Runtime object use it for his

own purpose, we would need to:

  • set all calls to this objects in other objects implemented by the

Runtime object

  • unset al theses objects before running the activity code

  • … well, no, I cannot see a fine way to unset all the GLOBALS from

egroupware… I don’t think it’s possible to prohibit completly the use

of egroupware’s connection.

  • The activity template is PHP code runned on the server, there’s no way

to have it runned in a secure way. We can break a LOT of things with

running PHP code on the server side, like files on the system - even if

you limit the avaibles directories, all PHP functions aren’t safe, even

with safe_mode (well, maybe you could list all unsafe functions and

prohibit them). And this workflow is designed to let the process

developers write PHP code for the server.

The only way we have to secure the activity code is to avoid complety

code edition by process developers (an acl to add, as we want them to

access the rest of the process edition) and hide it under pre-coded

features, something that is “in the road” in fact. But even if we are

smart enought to “pre-code” a lot of things and add a lot of parameters

this will make theses processes less powerfull (but that’s what we want :-).

It will be PHP code + automatic forms or automatic forms without PHP

code. And the second way is the only way to delegate it securely.

The only other way is adding a special basic language with an

interpreter and hoping it will be a good one, and this seems to be a

very hard way, not the Galaxia goal actually.

Régis Leroy,

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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

6

Fine,

If you can dig a little in this direction it’s a good thing.
One thing you can do to help you is running a doxygen on the workflow,
it will give you good starting points.
I’m here (on the list or private) for any question.
For code filtering there’re already some thing in
workflow/inc/engine/ProcessManager/ActivityManager filtering to give
some warnings (switch activity should use $instance->setNextActivity,
etc.), but it’s not a ‘PHP compiler’, it’s just scanning for strings,
quite easy to bypass if you really want to pass threw the scan.

Régis,

Mauricio Luiz Viani a écrit :

Hello Régis,

Thank you for your answer. I read it carefully and a agree with things
you said. I think that what is possible to do, at this moment, in our
case, is prohibit process developers from using Globals by filtering
activity code. I don’t know how to do this yet, but I’ll dig into code
and try to find a way. Of course this will make processes less
powerful, but I hope it will prevent processes developers from making
inappropriate access to egw database.

Following your directions about an external db connection, I’ll try to
develop a new agent to do this (similar to smtp agent already
available). If I had success, I’ll send you the code.

Regards,

Viani.

egroupware-developers@lists.sourceforge.net escreveu:

At first it should be possible (and it seems quite easy) to create
a db
connection specifically for an ADODB object usable by the templates
(maybe a db agent, handling persitence if possible).
Actually the AdoDb object is the AdoDB owned by the Runtime object
(and
derivated from egw's ADOdb object). This Runtime object use it for
his
own purpose, we would need to:
* set all calls to this objects in other objects implemented by the
Runtime object
* unset al theses objects before running the activity code
* ... well, no, I cannot see a fine way to unset all the GLOBALS from
egroupware... I don't think it's possible to prohibit completly
the use
of egroupware's connection.

* The activity template is PHP code runned on the server, there's
no way
to have it runned in a secure way. We can break a LOT of things with
running PHP code on the server side, like files on the system -
even if
you limit the avaibles directories, all PHP functions aren't safe,
even
with safe_mode (well, maybe you could list all unsafe functions and
prohibit them). And this workflow is designed to let the process
developers write PHP code for the server.
The only way we have to secure the activity code is to avoid complety
code edition by process developers (an acl to add, as we want them to
access the rest of the process edition) and hide it under pre-coded
features, something that is "in the road" in fact. But even if we are
smart enought to "pre-code" a lot of things and add a lot of
parameters
this will make theses processes less powerfull (but that's what we
want :-).

It will be PHP code + automatic forms or automatic forms without PHP
code. And the second way is the only way to delegate it securely.
The only other way is adding a special basic language with an
interpreter and hoping it will be a good one, and this seems to be a
very hard way, not the Galaxia goal actually.

Régis Leroy,

------------------------------------------------------- This SF.net
email is sponsored by: Splunk Inc. Do you grep through log files for
problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________ eGroupWare-developers
mailing list eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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

7

Some of the notes are here now

http://www.egroupware.org/egroupware/wiki/index.php?page=WorkflowTODO&lang=en

Régis,

Mauricio Luiz Viani wrote:

Hello Régis,

Thank you for your answer. I read it carefully and a agree with things you said.
I think that what is possible to do, at this moment, in our case, is prohibit
process developers from using Globals by filtering activity code. I don’t know
how to do this yet, but I’ll dig into code and try to find a way. Of course this
will make processes less powerful, but I hope it will prevent processes
developers from making inappropriate access to egw database.

Following your directions about an external db connection, I’ll try to develop a
new agent to do this (similar to smtp agent already available). If I had
success, I’ll send you the code.

Regards,

Viani.

egroupware-developers@lists.sourceforge.net escreveu:

At first it should be possible (and it seems quite easy) to create a db
connection specifically for an ADODB object usable by the templates
(maybe a db agent, handling persitence if possible).
Actually the AdoDb object is the AdoDB owned by the Runtime object (and
derivated from egw’s ADOdb object). This Runtime object use it for his
own purpose, we would need to:

  • set all calls to this objects in other objects implemented by the
    Runtime object

  • unset al theses objects before running the activity code

  • … well, no, I cannot see a fine way to unset all the GLOBALS from
    egroupware… I don’t think it’s possible to prohibit completly the use
    of egroupware’s connection.

  • The activity template is PHP code runned on the server, there’s no way
    to have it runned in a secure way. We can break a LOT of things with
    running PHP code on the server side, like files on the system - even if
    you limit the avaibles directories, all PHP functions aren’t safe, even
    with safe_mode (well, maybe you could list all unsafe functions and
    prohibit them). And this workflow is designed to let the process
    developers write PHP code for the server.
    The only way we have to secure the activity code is to avoid complety
    code edition by process developers (an acl to add, as we want them to
    access the rest of the process edition) and hide it under pre-coded
    features, something that is “in the road” in fact. But even if we are
    smart enought to “pre-code” a lot of things and add a lot of parameters
    this will make theses processes less powerfull (but that’s what we want :-).

It will be PHP code + automatic forms or automatic forms without PHP
code. And the second way is the only way to delegate it securely.
The only other way is adding a special basic language with an
interpreter and hoping it will be a good one, and this seems to be a
very hard way, not the Galaxia goal actually.

Régis Leroy,

------------------------------------------------------- This SF.net email is
sponsored by: Splunk Inc. Do you grep through log files for problems? Stop!
Download the new AJAX search engine that makes searching your log files as easy
as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________ eGroupWare-developers mailing
list eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

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