Understanding Permissions

A common source of confusion in SAP Enable Now implementations is that of permissions. In this article, we’ll look at the types of permissions that are available, and the way in which they can be applied.

Object permissions

First, there are some eighty (80) individual permissions that can be granted to a user (how, we’ll look at in a minute). For brevity, these are not listed here, but you can find a list in the Manager product manual, or here on the Enable Now Wiki. Largely, they provide display, create/edit, and delete access to various types of objects (although there are a few more specialist ones that should be granted sparingly) so we’ll refer to these collectively as object permissions.

An individual object permission can be granted to one of the following entities:

• An Organizational Unit – in which case it will apply to all Roles and/or Users within that Organizational Unit
• A Role – in which case it will apply to all Users who have that Role assigned to them
• An individual User

Although the OU > Role > User hierarchy supports inheritance (as noted in the list above), in general you should generally only assign permissions at the Role level. This will make things much easier to maintain – especially as permissions displayed at the User level do not indicate from where they were inherited. Specifically, avoid assigning permissions directly to a specific User; it may be tempting if you are in a hurry, and under pressure to resolve some particular issue, but it will cause more confusion in the long run. So take your time, and always define specific Roles with the appropriate permissions assigned to them.

You may also find it helpful to define your Roles in a separate ‘Organizational Unit’ (or directly under the root OU), again for ease of maintenance. Bear in mind that Roles here are ‘Roles within SAP Enable Now’, and not business/operational roles, so any organization of Roles within the OU hierarchy is purely for the convenience of (you as) the Administrator.

SAP Enable Now comes with several pre-defined Roles (which have a recommended set of permissions assigned to them). These are:

• Guests
• Learners
• SMEs
• Standard Authors
• Master Authors
• Reviewers
• Project Managers
• Report Reviewers
• Administrators
• System Workarea

You can enable/disable these standard Roles as required, define your own Roles, and change the permissions assigned to each (standard or custom) Role as required to meet your specific requirements.

Object permissions are granted via Manager menu option Administration > Permissions, which will display a screen similar to the following:

This screen consists of three columns. These are:

• Selection: This provides a consolidated list of your entire organizational hierarchy, showing the Roles and/or Users assigned to each Organizational Unit (note that Users are listed under the Organizational Unit, and not under a Role – if you want to see which Users have a particular Role, you will need to use the Administration > Roles menu option, instead).
• Permissions: This is a complete list of all the permissions available in SAP Enable Now. Any of these that have been directly assigned to the element (OU, Role, or User) selected in the Selection hierarchy on the left are identified by a selected checkbox to the left of the permission name (as shown for the Scheduler: * permissions in the example above).
• Assigned Permissions: This is a list of all permissions that have effectively been assigned to the selected element. This can be through inheritance (for example, they are applied to a Role that the selected User has assigned to them) or through direct assignment (that is, selected in the Permissions column.

To change the permissions assigned to an element:

1. Select the element (OU, Role, or User) in the Selection hierarchy.
2. Select or deselect the checkbox(es) for the permission(s) in the Permissions list.
3. Click the Save button.

Note that you cannot remove a permission that has been assigned through inheritance – you can only grant additional permissions. (If you need to remove specific permissions from a User, you should create a new Role without the permission, and assign that new Role to the User, instead). In the same spirit, Users will always be granted all of the permissions for all of the Roles assigned to them – so if a User has Role A which has the Workareas: Create permission, and also has Role B which does not, they will have the permission.

Workarea permissions

Object permissions determine the actions that can be performed against individual objects (including Master Data objects, Resource objects, and even Workarea objects). However, it is not enough to have permission to perform certain actions on certain object types – you also need permission to perform these actions within a specific Workarea. This is the concept that trips up many new SAP Enable Now Administrators.

Workarea permissions are a higher level of permission, and – again – should always be assigned at the Role level. Effectively, they say “these object permissions apply within this specific Workarea. Given that Users (and Roles) are also defined at the implementation level, Workarea permissions are the only way to limit a User (or Author) to a specific Workarea. Fortunately, there are significantly fewer Workarea permissions, ostensibly providing broad ‘display permissions’ vs. ‘write permissions’. Again, default Workarea permissions are defined as part of the initial SAP Enable Now implementation. However, if you define any additional Workareas, you will need to assign Workarea permissions to them yourself.

To change the permissions for a Workarea, go to Manager menu option Administration > Workareas / Tags, and click on the Permissions link for the relevant Workarea. This will display a dialog box similar to the following:

Select a Role in the upper portion of the screen, and then select the permissions that this Role should have for this Workarea in the lower portion of the screen. Thankfully, there are many less permissions at this level. These are:

• View Published Content: Allows (users who have been assigned) the selected Role to view published content. Normally, all roles would have this level of permission.
• View All Content: Allows (users who have been assigned) the selected Role to view all content, regardless of whether this has been published or not. This level of permission should only be granted to Authors (Standard/Master), and also Reviewers. It should not be given to Learners.
• Create, Edit, and Delete Content: Allows (users who have been assigned) the selected Role to create, edit, and delete content objects – as long as they have the relevant object permission. This should be granted to all ‘producer’ roles (for example, SMEs, Authors, Reviewers).
• Delete Workarea: Allows (users who have been assigned) the selected Role to delete the Workarea. This should only be assigned to Administrators.
• Administrate Workarea: Allows (users who have been assigned) the selected Role to maintain the Workarea’s settings. This should only be assigned to Administrators.

Group permissions

Unfortunately, SAP Enable Now does not provide the ability to define permissions at the Group level (sorry if I got your hopes up with the heading!). However, this is an often-requested feature, and SAP have indicated that it is “being considered”, so hopefully we will see it one day.

Such a feature would allow you to limit Authors to only creating or changing content within a specific Group within a Workarea. This would provide greater ‘security’, especially where there are multiple content development organizations working within the same Workarea, or – for example – to limit only Master Authors to changing the contents of the Toolbox (including Templates and other shared assets).

In the meantime, if you really do need to limit the scope of Authors, you will need to use separate Workareas, with separate Roles and Workarea permissions. Just bear in mind that using separate Workareas will hamper your ability to re-use content and share common assets.

Summary

So, in summary, if you need to grant a user a certain permission to perform a specific type of action for certain object types, and only within a specified Workarea, you should (best practice) assign the relevant object permission to a Role, assign that Role to the User, and ensure that the Role has the appropriate Workarea permission for that Workarea.