Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • These are settings that mostly controlled via the Administrate view, they allow an admin to adjust the overall function of the evaluation system for a Sakai installation
    • All updates and retrieval of system settings are done via the Settings API
    • All settings are referenced via constants in the Settings API
  • System settings can be removed by updating the setting to a value of null
  • Boolean override (ternary) settings are special and should have 3 states
    The override settings are those which basically override a configurable setting elsewhere in the system (e.g.
    • TRUE - All settings in the system must match this
    • FALSE - All settings in the system must match this
    • NOT SPECIFIED (NULL, which is not stored) - Settings may be set to true or false
  • Other setting types can be overridden as well as needed
  • Boolean and ternary booleans settings are listed in arrays in the EvalSettings API file so the system knows about these settings and can handle them correctly
    • All boolean and ternary settings must be listed in the array constants
    • Boolean settings are guaranteed to return true or false and will not return a null
  • Settings are cached to reduce database load
    • The cache is as cluster aware as it can be in Sakai and should flush out the values when they are changed
    • There is also an automated timed process which reloads all settings every hour


  • Entities refer to persistent objects in the evaluation system
    • Entities should be comparable to each other using object equality


Protected fields (fields which should not be modified at certain times)


  • Items can be added to evaluations while they are in-queue but not yet active (depending on settings), these items are typically referred to as instructor added items. These items are stored in a separate template from the original one used to create the evaluation (this is to avoid the locked template issue and avoid corrupting the original set of items)
    • The secondary template is created when the first added item is placed in the evaluation
    • Secondary templates are flagged using a field and constant variable
    • Secondary templates should not appear in the list of templates and are managed by the system only
    • Items within the secondary template have 2 fields which are used to store the hierarchical location of the template item
  • Eval takers should only see the items applicable to them, a method in the logic layer will return the correct items for an evaluation and user and correctly handle the logic for filtering items
  • Question adders (instructors or admins) should only have access to change the items they are adding and yet need to be able to see all items in the evaluation above their level so they know what else exists in this eval, this will allow them to reorder their own items but not mess up the other items in the evaluation template

Adhoc users and groups

  • Adhoc groups and users (created as needed) are stored in the eval database
    • these allow the user to define a group of email addresses to send an evaluation to
    • Adhoc users
      • essentially like real users which come from Sakai except that they are stored in the eval system
      • adhoc users have no password at this time so adhoc users get to skip the authentication step
    • Adhoc groups
      • essentially like external groups, sites, or site-groups except that they are stored in the eval system
      • no permissions are associated with adhoc groups except the ability to take evals assigned to that group, evaluatees in adhoc groups do not have the ability to create templates or begin evaluations


  • The implementation will take an "optimize last" approach. We will finish the functionality for a milestone before we attempt to optimize the performance.
  • Some optimization is designed into the system via the data model and the business logic layer methods