...
This brings us to some extremely important points about execution.1.
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. The reason is you can only schedule one single xaction to run per schedule, but you can create as many schedules as you like.2. No roles normally associated with the user are assigned to them when things are run through the scheduler. This means you cannot use Mondrian, Analyzer or any other component that depends on roles, because these roles will not be passed on to Mondrian. You can have a completely open schema, but this means that you will have separate caching for each schema in Mondrian. One for your secured schema that depends on roles, and a separate cache for the unsecured
schemaWe 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.
...