A Solution for Enabling Sandbox activation by non admin users for testing (OIM 11gr2 PS2)

Question

I just wanted to post what i came up with as a solution the the problem of not being able to Test the effects of sandbox changes for non admin level users prior to their publication.  We are constantly making changes to the UI through sandboxes, the problem is rolling a sandbox back isn't easy, and we cannot be sure of the effects they will have on non administrative users until they are published, since the out of the box sandbox link isn't available to non Sysadmin level users.
To allow these non admin user accounts to test the effects of sandbox changes in our development environment, I did the following (as always, follow at your own risk):
Create and activate a new sandbox.
Close all open tabs (including the Home and Sandbox tabs) and click the "Customize" link.
Click the view -> source drop down in the upper left.
After the source is visible, click the Accessibility or Sandbox link to find the area that you will add the new "UserSandboxTest" (call it whatever you want) link.
Add a new commandImageLink directly in the panelGroupLayout: horizontal item before the "switcher" item (see the UserSandboxLink in my screen shot below):
Edit the Link you just inserted, Entering whatever you want the link to display as in your browser in the "Text" field.
Export the sandbox.
Unzip the exported sandbox and navigate to the IdmShellV2.jspx.xml (path should be: \templates\mdssys\cust\site\site).
Edit the IdmShellV2.jspx.xml file and find the new item you added in step 5.
Add the following to the commandImageLink xml item: actionListener="#{pageFlowScope.uiShell.context.launchSandboxes}" rendered="#{oimcontext.currentUser.roles['SANDBOX_USER'] != null}".  Note: I used a new custom enterprise role, SANDBOX_USER, to control the display of the new link, You should substitute whatever EL conditions you need in the rendered property.
Save your IdmShellV2.jspx.xml file and zip the contents back up, just like you would for any other customization.
Import your newly edited sandbox back into the target environment.
Publish the sandbox.
This seems to work great for allowing us to test other sandbox changes effects on different types of users. 

Answer 1

On step 10, adding the check to determine if the user should have access to the role ended up breaking access to the unauthenticated pages like the self registration page and the forgot userid/user login pages.  Non-authenticated users cannot execute the method to return the role, so that fails which leaves the page not loading.  To correct this I changed the rendered property to rendered="#{securityContext.authenticated}".  This prevents the link from displaying on non authenticated pages, but displays for anyone else who's logged on.  We only plan on using this in our development environment where no one but developers and system admins have access anyway, so it's not an issue that everyone will see the link.  I wouldn't recommend putting this in an environment where end users will be logging in and testing without developing a method (or finding another way to limit the display) that can be called by unauthenticated users to prevent them from seeing the link.