Scheduling xactions from the Pentaho Admin Console
- Former user (Deleted)
This document is current for 3.6 and 3.7 of the Pentaho BI Suite.
The Pentaho Admin Console -> Scheduling xaction section
Depicted below is the Pentaho Administrative Console interface typically used to configure the BI Server itself. The administrative console generally does not do anything extremely sophisticated. Usually altering settings on the various menus cause changes to be written to .xml files contained in the pentaho-solutions/system directory.  For our case, changes will actually take place in the Quartz scheduler, which stores it's configuration in a database, typically MySQL.
Rules of engagement
It is important to know that when you create scheduled items on the screen above that without exception they execute as the user you have defined as the 'system user'. On a default install this is usually 'joe' with the samples, or 'admin' without samples. You will see we choose the user 'dtruty' as it is a valid username in our setup. Valid means that it is a real user account that has permissions on our network and will not disappear.
This brings us to some extremely important points about execution.
If you execute your xaction from the schedule in Pentaho Administrative Console depicted above
No startup xactions run before or after a scheduled xaction is run. If you want session variables, you'll need to add them as a sub-xaction of whatever you're scheduling or chain them in order of execution. You can schedule many xactions to run per schedule and create as many schedules as you like.
We did an experiment with an xaction that when run would grab the security:principalRoles and security:principalName from the environment and email them to ourselves. When attempting this from the Pentaho Administrative Console, the xaction failed to execute. No messages were logged to catalina.out or pentaho.log. Other xactions work fine. This may be a bug in the Pentaho platform. The xaction is attached.
A customer support case with Pentaho revealed that the only role returned is "Authenticated" for whomever you defined as the system user. Due to the problem encountered above, we could not prove that to be the case.
If you schedule your xaction from the PUC (Pentaho User Console), it runs with your rights.
Normal users of the Pentaho system benefit from startup xactions and roles. If you schedule an xaction to run periodically while logged into PUC, it will run with those roles and session variables established upon normal login. Your scheduled content will execute even if you are logged out of the system.
Practically, this means that if you have some content that depends on roles (Secured Mondrian schemas) or session variables (You have some reports consume session variables), you should schedule them as a user with the appropriate rights. You if you set the content to run correctly as your own username, then schedule them all together. The only downside is that you have to delete the schedules you create from the Pentaho Administrative Console.  Also you cannot create this special kind of schedule directly from Pentaho Administrative console. It is clearly a loose end that needs some love.
In the picture below the Platform Administrator User Name is "dtruty". If you were to schedule a report that used env::principleName, the value returned would be dtruty. No roles or other session variables would be available to the report unless your xaction explicitly set them.
Examining the meaning of the word group.
Where you see the word "Group" in the picture is the name you are giving to the particular schedule. It has nothing to do with a role, access group or any security related concept. Groups simply allow you to schedule say two separate kinds of things to happen at different times under one name. You can make the schedules public and by doing so, other users who through the Pentaho User Console decide to schedule their reports will be able to have them run attached to the schedule you made public. This does not mean that other users gain access to whatever was scheduled by the individual in the Pentaho User Console.