PeopleTools | Using Definition Security to restrict App Designer access
A. What is Definition Security?
Definition Security adds yet another layer to the vast web that is PeopleSoft security. It does this by controlling access to App Designer objects. By setting up a ‘Group’ in Definition Security – and then linking that group to a permission list – you can grant update or read-only access to a specific set of objects. This could be in the form of records – as we’ll use in the example below – or it could be any object type normally associated with App Designer.
Most people are unaware that Definition Security even exists. This is because developers are usually granted full access to all App Designer objects via the system-delivered ‘PeopleTools’ security role. Given that developers typically have unrestricted access in a development environment, Designer Security rarely comes up as an issue. It only becomes important when you need to restrict access to App Designer for whatever reason.
Designer Security can be accessed in a couple of ways. You can either navigate in the browser to PeopleTools -> Security -> Definition Security, or you can use the more traditional Windows-based approach, available via App Designer.
Although the Windows software looks old-fashioned and ‘clunky’, it has one key advantage over the browser. Some of the PeopleSoft object types contain thousands of items, meaning you may fail to receive a response from the browser if you attempt to load too many objects at once. The older Windows software doesn’t have this problem as there is no concept of a ‘time-out’. In the example that follows, I will be using the App Designer Windows approach.
B. Steps for Restricting App Designer Access
To see how Definition Security is configured, we will next work our way through an example. The users in this case require update access to five custom SQL views. While we’re happy for the users to modify these views, we don’t want them accessing other PeopleTools objects in the system.
(i) Set up Definition Group
Once you’ve logged into App Designer, select ‘Go’ from the main menu, followed by ‘Definition Security’. If you cannot see ‘Definition Security’ listed under ‘Go’, you will have to speak to your system administrator to have the necessary access granted. Alternatively, you can try the browser portal option described earlier.
If you do have access in App Designer, the Definition Security window opens as below:
In this window, select File followed by ‘New Group’. The page display should change as follows:
In the dropdown box in the top left-hand corner, specify the object type that you wish to configure. In this case, we will specify ‘Record’. The display then changes to show all available records in the right-hand side column:
You will notice that the left-hand column is called ‘Records’ while the right-hand column is called ‘Excluded Records’. I am going to suggest that you ignore these column headings entirely as they only make the process more confusing. Instead, better column headings would be as follows:
Left: Locked, Not Available
Right: Unlocked, Available
So in other words, looking at our example above, every single record is currently marked as available by default. However, in our case, we only want to grant access to a limited set of records. We must therefore set the vast majority of records to ‘not available’. To do this, click the double-arrow button in the centre of the window to move all objects from right to left. This might take some time depending on the number of records in your database, but eventually, you will see everything has been shifted across:
Now we can go ahead and find our five custom records on the left-hand side, and copy then back to the ‘Available’ column on the right. This we do by highlighting the record on the left and then clicking the single transfer arrow. The display should end up as follows:
Finally, save the Definition Group by selecting ‘File’, followed by ‘Save’.
At this point, you could add other objects to the Definition Group by picking a new object type in the top left-hand corner. However, we will restrict this example to records only.
(ii) Set up Permission List
Now that we’ve created the Definition Group, we can go ahead and add this to a Permission List. To keep this example simple, we will create a new Permission List from scratch.
Start by going to PeopleTools -> Security -> Roles and Permissions -> Permission Lists. Then select ‘Add a New Value’. Specify a Permission List name and description.
Next, click on the ‘PeopleTools’ tab and grant access to App Designer by ticking the relevant checkbox. Once you click the checkbox, two hyperlinks become active. These links allows you to fine-tune control the required access to App Designer, however for our example, no further action needs to be performed. We only need to click the checkbox for now:
After this change, go to the ‘Definition Security’ tab right towards the end of the component. In the grid, specify the name of the Definition Group that you created above:
Finally, in the same ‘Definition Security’ tab, click the ‘Definition Type Permissions’ hyperlink under the grid. All App Designer object types will appear as a long list. In this case, we are only interested in records, so we will set the ‘Records’ row to ‘Full Access’:
Click OK and save the Permission List.
(iii) Set up Role
Go to PeopleTools -> Security -> Roles and Permissions -> Roles. Then select ‘Add a New Value’. Specify a Role name and a description.
In the ‘Permission Lists’ tab, specify the Permission List created earlier:
Save the Role.
(iv) Add Role to User Profile
Go to PeopleTools -> Security -> User Profiles-> User Profiles and open up the user that needs the limited App Designer access. In the ‘Roles’ tab, specify the Role created above:
Save the User Profile.
Note: if your user has a large number of Roles – often the case when the User Profile is originally copied from the ‘PS’ account – you may notice that the Definition Security does not work correctly. Colleagues of mine have looked into this problem and have been unable to determine the cause, but we assume it has something to do with conflicts between different Roles. The problem never happens for users with a more limited set of Roles.
(v) Test App Designer
You can now test in App Designer to see whether the access works. Ask the user to log into App Designer and try opening one of the allowed records. No error should appear. Test that the user can make a change to the record and save.
Next, try opening any other record (or any other object type), and the user should receive an error specifying that access is restricted:
Our requirement is complete. We have successfully restricted access to App Designer.
See Also: