|
Catalog Access
Your catalog design should allow for structural authorizations if you need to restrict access to certain portions of the catalog to specific populations. You might want to prevent training administrators from France to create courses under a business event group that belongs to a training organization in the United States. Structural authorizations allow to restrict access to specific plan versions, object types and object ID's.
You can also restrict the display depth. For example you might allow a user to see the business event group "Languages > French" but prevent him from accessing "Italian". If you need to implement structural authorizations, your catalog design should be very decentralized so that specific user groups are granted access to a specific hierarchical node. You want to keep this as simple as possible.
You have to consider that should you add a new business event group that is not linked to a business event group your user currently has access to, then his/her authorization profile needs to be updated if they need to access this new business event group.
Structural authorizations are the most effective way of preventing access to certain portions of the catalog but they are often time consuming to maintain and slow down reporting - especially of your business event catalog is very large.
An alternative to structural authorizations is the usage of "views", a system usage guide and a naming convention, which we will cover later on. Administrators can restrict access by manipulating their administrative settings and choose to display only that portion of the catalog that they are using to manage their courses. This prevents users from accidentally creating courses under the wrong business event group and displays only a fraction of the catalog - the one that they work with. This little switch is activated under a person's user defined settings, which he/she can access from the business event menu.
Here users can enter the ID of the root object (event group or type) to be read when accessing the business event menu - only the root object will be read with all appending objects.
It also is advisable to compile a "system usage rules" document if you do not implement structural authorizations. This document should outline what administrators are allowed to do and what they should refrain from doing, for example carry out billing for a business event that belongs to a different training organization, increasing the capacity of someone else's fully booked business event in order to place another candidate, creating courses under a business event group that "does not belong to them" etc. Again, the design of the business event catalog should help here - each training organization should logically own a portion of the event catalog.
This 'system usage rules" document should be distributed and explained during training.
|