Hierarchy

Information

This discribes the hierarchy design and implementation notes for the Evaluation Hierarchy.

Hierarchy

• A hierarchy level is represented by a levelId which must be unique and must not change
• Users may have access to various levels of the hierarchy, by default the system assumes that having access to a level of the hierarchy gives the user access to all levels beneath that level as well
• Data requested:
  • Hierarchy traversal
    • the top node (root) id of the hierarchy (there must be one only)
    • the parent node id of a specific node id
      • Do we need to support multiple parent nodes?
    • all hierarchy node ids directly beneath a specific node id
  • Groups
    • the set of all nodes in the path from a specific group to the root node
    • the set of eval groups (course/contexts) beneath a specific node id
  • Permissions checking
    Permissions: View data, Start evaluations, Control templates/items/scales (others?)
    • the set of userIds which have a specific permission to a set of hierarchy nodes
    • the set of hierarchy nodes which a specific userId has a specific permission in
    • check for a specific permission at a specific hierarchy node

Hierarchy Functional Requirements

• Notes from discussions at Michigan during week of May 29, 2007.
• Notes from phone call with Aaron on May 31, 2007.

Interface for external providing of hierarchy

• This is the current application programming interface for an external hierarchy provider
  EvalHierarchyProvider.java
  • provides methods to get hierarchical data into evaluation system for use in determining the structure above evaluation groups related to adminstration and access to data and control of evaluations for certain subsets of eval groups