2006-09-19 Agenda and Notes

Owned by Former user (Deleted)
Last updated: Sept 20, 2006 by Former user (Deleted)Version comment
4 min read

Weekly Meeting Agenda for September 19, 2006

In attendance: ???

Notetaker: Daphne

Agenda

  • from last time:
  • new business
    • review initial design decisions for CM-aware Section Info
      • SIS sections become/override a descrete section category
        • can't create/delete/update sections in this category
        • can't re/move SIS provided students
        • can add manually-added members (e.g. guests)
      • other roles (e.g. instructor, head TA, others > student) can be "section leaders"
      • once a student shows up in SIS data, they are assigned to a section

see attached slides

Notes

In attendance: Daphne, Oliver, Josh, Judy, Marc, Lydia, Duffy

Section Info

  • See agenda for notes
  • Need to think about what happens if sections are created manually and the SIS sections of the same type come in. Do we automatically override? This could be really confusing. We could include a confirmation workflow.
  • Reconciliation needs to happen when students added manually and then they come in from SIS. Lots of discussion around whether this can happen and how. What if student gets manually added to SIS defined section, then SIS defines them in another section. Currently the framework does not support checking to see if a student is in another section of the same type. So... If a student is added to lab 3 and then SIS brings them in as lab 2, the system won't recognize the conflict. See to do list. Josh is looking into this.
  • Josh explained why the framework doesn't support this. Here's the brief (warning) summary: When a roster is added to the site, a new group will be created, and the group will have its provider id set to the roster's id. This way, the site's groups will exist and be populated immediately upon site creation. This feature should work well for generic groups. However, we'll run into problems when we're dealing with sections because sections have additional business rules regarding memberships. In particular, a student can be in only one group per category, where category is just the group's "sections_category" property. This business rule will cause problems with provided groups, since a user may be added to a group without removing them from other groups in that category. There is currently no programmatic "hook" into the framework to intervene in the manual / roster-feed membership reconciliation. I've asked Glenn about the possibility of adding this feature.
  • Distinguishing between SIS defined students and manually added students
  • SIS data provided students at Stanford are "enrolled students" and manually added are "students". The permissions are basically the same.
  • If manually added and then gets SIS defined, how is that identified? Josh suggests to look at qa and test to see what happens with sites now. That's how sections should happen too.
  • Could have 2 roles if we need it, "officially enrolled" and "manually enrolled".
  • Can we separate out roles from enrolled status? Manually added and SIS added students have the same permissions so they should have role. We need a different
  • Interesting idea about logging changes the framework has made. "Show me the changes you've made to section membership."
  • Josh: we just need to write test cases and run them by Glenn
  • Identifying students
  • Stanford uses eid to identify students
  • Berkeley uses uid from ldap but eid is the same?
  • Duffy says SIS defined information isn't always the "trump" over manual. He says this is probably an edge case and we can ignore for now. If it comes up later maybe it could be an enhancement.

Connecting Rosters to Sites (who can?)

  • Dept. Admin
  • can they associate a roster with a site? If we allow this we'll need to make it clear that they have this ability. All rosters for their dept. show up in the list of courses/sections to choose from during site creation and roster edit?
    • They have instructor access to all courses within their site. Do they show up in the membership list? Aren't really members but instructors should know they have access to the site.
    • Is this a setting at the department level? Some departments may want the ability and others not.
    • Do we need a new out of the box role? What can dept. admins do? We need to define what this is. We could define permissions for out of the box and then each institution can edit those roles as needed.
  • ¿ At Stanford, dept. admins are super users for a subset of sites (departments). They need access to the admin tools for their sites. Josh says this is really difficult and the admin tools are set up for this type of filtering. This is a very different problem that the dept. admins as instructors. Marc says this seems to be outside of the CM scope. CM service may feed information to help this happen but not part of this project. Dept. Admin will see all courses & section within their dept. Marc will go back and get more information from his folks. He'll likely punt on this one to Casey.

To Do:

  • Josh to look into how we can reconcile SIS defined and manually defined section membership
  • Section requirements from agenda
    • Change "can't add/delete..." to "can't add/delete/update"
    • Add "Can't create manual sections of the same type that are already defined by SIS
    • Add "Need to be able to turn off SIS management of sections so instructor can manually manage at any point during the semester".