Zone and Org-Units

 

Zone

org-unit

Version 1

Version 1

 

 

ID

ID

Name

name

full name

full name

Description

description

 

 

 

 

 

 

 

 

 

 

ACL

ACL

 

 

 

 

 

 

 

 

Children

children

default authentication mode

 

contacts: web URL

contacts: web URL

contacts: email

contacts: email

contacts: trouble

contacts: trouble

data source

data source

data key

data key

Parents

parents

Terms

terms

roles: instructors

roles: instructors

roles: instructor staff

roles: instructor staff

roles: admin staff

roles: admin staff

roles: content dev

roles: content dev

roles: majors

roles: majors

roles: guests

roles: guests

 

Zones and Org-Units provide a way to model the basic organization that is using Stellar.  In the simplest case, the zone is the org-unit (there are no departments, etc. within the organization).  The only separation between the zone and the org-units is that the zone has a "default authentication mode" to allow easy identification of the preferred authentication mode within a site.

 

Other attributes include:

  1. Version Number*: 1.  Will allow revision of the data format while still using existing data.  For example, we may find a different type of organizational unit requires different or additional data and want to add that while still using the already established organizational units.
  2. ID number*: unique ID provided by stellar for all data objects
  3. Name*: short name for common use
  4. Full Name*: complete name used for formal occasions
  5. Description: (optional) short textual description
  6. ACL*: list of groups (or individuals) with default access rights.  Key here is that this defines administrative rights to add information.
  7. Children*: either Org-Units list OR course-instance list(s) [note that organizing the course instance lists by term will be helpful for long-term use.  OR should this be only the active course-instances?  In which case where do we link the "retired" course-instances and the upcoming course-instances?  My proposal: make the course-instance list(s) actually lists of lists, with each list identified by a term and containing the appropriate course-instances for that term.)
  8. default authentication mode (zone only): currently defined X.509, username/password
  9. Contacts info: web URL, email, trouble (at least the email and trouble reporting should be required*)
  10. Data Source*: where do we obtain this information?
  11. Data Key*: how does that source identify this?
  12. Parents: the organizational units are defined as a hierarchical structure.
  13. Terms: this identifies the time periods associated with course-instances
  14. Role lists: these are lists of users identified with specific roles within an org-unit.  Currently identified are: instructors, instructional staff, administrative staff, content developers, majors, guests.  At a minimum, an org unit must identify administrative staff to construct course-instances and other data.  In most cases, the org unit will identify at least instructors, administrative staff, and content developers.

 

Functions needed:

 

CreateZone

CreateOrgUnit(parentID, )

SetOrgUnitxxxxxx(ID, parameter)

 

GetOrgUnitxxxxxx(ID)

GetOrgUnit(ID) returns all info?

FindOrgUnitbyName(name) returns ID

GetOrgUnitTerms(ID)

 

We need forms to allow easy creation and editing of the OU information.

 

We also need to consider how this information would be rendered.  I would expect that one "mode" of getting to a course instance might be to start at the zone "page" (which may be dynamically built), then work "down" through the org-unit "pages" until you get to a page listing the current course-instances.  This would especially be useful for people visiting the publicly available view of a particular course-instance.