Settings
Settings can be the glue that holds the different aspects of a client application together. They allow the creation of additional functionality, beyond the basic functionality provided by the stored procedures. Settings are one of the primary components provided to developers to control different aspects of security for individual users and to protect the site in general. Settings also allow the storage of information inside of the existing database structure for any additional structure an app would like to create.
User Settings
User Settings can be divided into 3 primary properties.
- Scope - The area of the application that the setting applies
- Permission - A users ability to alter a setting
- Visibility - A users ability to see a setting
Scope
Scope determines the particular group of users that the setting affects. Keep in mind that even though Scope allows a single setting to apply to many users, the setting ultimately only applies to the user that is currently logged in.Scope is created by the function used to manipulate the setting. These functions come in 5 layers to create 5 scopes.
- set_system_default_setting - This level affects all users in the system
- set_school_default_setting - This level affects all users in the school
- set_user_default_setting - this level affects a specific user in all of his or her courses
- set_course_default_setting - this level affects all users in a course
- set_user_setting - this level affects a specific user in a specific course
These layers overload each other respectively with the highest layer being user_settings and the lowest layer being system_default_setting. So, if a user wants to assign a specific setting to a course that does not affect any other courses, he or she would use set_user_setting. However, if they had set a setting using set_user_default_setting then that would apply to all other courses except the one with the above user_setting that was overriding it. Since any system setting can be overriden, how can an administrator protect system settings that not-adminstrators should not be able to change. This is where permissions come in.
Permission
Permission determines if a user can change a setting or not.There are 4 permission levels
- 999: admin
- 3: instructor
- 2: TA
- 1: student
For settings that do not apply to a course, namely system_default, school_default, and user_default only two of those levels are relevent.
- 999: admin
- 1: student
Visibility
Visibility determines if a user can see a setting. Even if you don't want a user to change or use a setting, it needs to be visible if you want it to affect the users browser in any way. These permissions are used in two ways. You may not want an individual student to change specific low level database settings or even see them. As such, the permission parameter blocks a user from setting a setting, and the visibility parameter blocks users from seeing a setting based on the user’s status in the above permission levels. The set_user_default_setting and the set_user_setting commands only apply to a specific user and do not require a user to block access to him or herself. As such, they do not include permission and visibility parameters. set_system_default_setting and set_course_default_setting are where permissions are set and can override, block, or hide the individual user setting.There are other setting types that are attached to specific database objects. Each message has a setting attached to it. Anyone who can view this message can see that setting. The same exists for other database table objects.