Versions Compared

Key

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

...

  • There are fields on many of the persistent objects that should not be modified once the object has been created (i.e. first saved in the database), the objects and the fields are documented below
  • Note: ID field is a special case, the id field on all persistent objects should never be modified in any way whether the object has been created or not
  • Persistent Objects (fields cannot be changed after object is created):
    • Answer
      • response
      • item
    • AssignContext
      • context
      • evaluation
    • EmailTemplate
      • defaultType
    • Item
      • locked
    • Response
      • owner
      • context
      • evaluation
    • Scale
      • locked
    • Template
      • locked
    • TemplateItem
      • template
      • item
  • Evaluation is a special case in that the state affects what fields may be modified
    The list belows details what changes are allowed at each state of an evaluation
    • InQueue (cannot modify)
      • locked
      • template
      • instructorOpt
      • termId
    • Active (cannot modify)
      • locked
      • template
      • instructorOpt
      • termId
      • availableEmailTemplate
      • reminderEmailTemplate
      • startDate
    • Due (cannot modify)
      • locked
      • template
      • instructorOpt
      • termId
      • availableEmailTemplate
      • reminderEmailTemplate
      • startDate
      • stopDate
    • Closed (can only modify)
      • viewDate
      • studentsDate
      • instructorsDate
    • Viewable (No changes can be made at all)

Evaluation added items

  • 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

Optimizations

  • 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