if we really need to run the script as a special user, we could just pass the users credentials as event parameters. but in our case we probably don't need that, because for automatically executed workflow teps it is not clear which user is used. i see 2 options here, first is to allow the workflow designer to add a user to the steps (as we did with steps that needs user participation). second is to use a special workflow user (or at least the admin as we currently do).
- Alex On Feb 19, 2008 9:05 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > well, if you need to execute the scripts as the user that produced the > event, > you need to 'sudo' to the correct session. since the sling api lacks > of a concept of a session - it's all tight to the > request,resolver,resources that somehow incorporate the session. > > so generating the mock request or the execution context or whatever > needs to be able to retrieve the correct session from anywhere. > > On 2/19/08, Philipp Koch <[EMAIL PROTECTED]> wrote: > > > just keep in mind, that the scripts must be executed with the correct > > > (jcr) session. the jobs that are executed by the event handling might > > > to all run as 'admin'. > > where is the difference? you have to pass the correct session in both > > usecases, or did i miss something? > > > > regards, > > philipp > > > > On 2/19/08, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > > just keep in mind, that the scripts must be executed with the correct > > > (jcr) session. the jobs that are executed by the event handling might > > > to all run as 'admin'. > > > > > > regards, toby > > > > > > On 2/19/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > > > On Feb 19, 2008 5:50 PM, Carsten Ziegeler <[EMAIL PROTECTED]> > wrote: > > > > > The question is which case is the special case? The one with the > request > > > > > or the one without? Thinking of executing scripts as the task of > the > > > > > script engine, this is foremost nothing to do with request. So, > > > > > personally, I see the request case as the special case :)... > > > > > > > > Ok, I might be off-base but in his post Alex says: > > > > > > > > > ...getting a ResourceResolver and executing a script without a > request at hand, > > > > > eg. within a thread that was triggered by an (job) event, would be > cool for > > > > > applications that goes beyond plain content delivery.... > > > > > > > > The ResourceResolver made me think that he needs a more complete > > > > environment than just executing a script. > > > > > > > > But yes you're right, if the use case can be simplified to not > require > > > > a request, more power! > > > > > > > > -Bertrand > > > > > > > > > > > > > -- > > > -----------------------------------------< [EMAIL PROTECTED]>--- > > > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 > Basel > > > T +41 61 226 98 98, F +41 61 226 98 97 > > > -----------------------------------------------< http://www.day.com>--- > > > > > > > > -- > -----------------------------------------< [EMAIL PROTECTED] >--- > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel > T +41 61 226 98 98, F +41 61 226 98 97 > -----------------------------------------------< http://www.day.com >--- > -- Alexander Saar Mobile: +49.177.5985437 E-Mail: [EMAIL PROTECTED] Web: http://alexander.saar.googlepages.com Blog: http://weblogs.goshaky.com/weblogs/saar/
