Script include is running under permissions of user who invoked it - how do I get it to run under admin privileges?

[oacp]

Hi,

I have a UI Action which calls a script include to carry out certain actions on users referenced on the selected records in a list.

The functionality has been tried and tested and is fully functional.

However, there is one glitch which I am unable to solve:

The script include contains a function which cycles through the relevant users, carries out the relevant actions and pushes the users' names to an array for later use in an alert message. This works fine if the users being cycled through are active users.

However, if a non-admin uses the UI Action to remove roles from an inactive/locked out user, the script will not pull back the users' names for the alert message and also does not remove the roles from the user.

I understand that this is because the user clicking the UI Action does not have the correct roles/permissions to view inactive users (as inactive users are only accessible to admins) but how can I ensure that the function in the script include can access this information?

I.e. the script include seems to be running under the privileges/permissions of the user who invoked it - how can I ensure that the script include runs with 'system' or 'admin' privileges to access back-end data?

[Brad Tilton]

I think the issue is that there is a query business rule running on the user table that filters out inactive users if you don't have a certain role. Unfortunately I don't think there's really a way around this since it's running at the db level other than editing that business rule or deactivating it and handling that security through ACLs.

[larstange]

Hi

The business rule "user query" does prevent normal users from accessing inactive user records.

I have a service catalog item where normal user do need to select an inactive user from a reference variable and I have solved it using "session data" this way

1. The business rule has been modified with the following added to the condition:
   && gs.getSession( ).getClientData('searchInactive') != 'true'
2. In the catalog item when the user trigges a search via a special field i have created, it calls a script include to perform the search. In the script include I do this before I access the sys_user table via a gliderecord. :
   
   

   gs.getSession( ).putClientData('searchInactive', 'true'); //Put session value to disable BR 'user query' temporarily

   
   Then after I have received what I need, i "close" the access again with this line
   
   

   gs.getSession( ).putClientData('searchInactive', 'false'); //Enable BR 'user query' again

You can then control in a specific user session when a user will actually be allowed to access inactive user records