SWG Working Session (IC & AZ) 2021-07-20

Participation

Support

Ann Su - Ed-Fi Governance Support

Meeting recording LINK

The meeting was held on 2021-07-20 2:00Pm -3:00pm CT via WebEx

Meeting Notes

Problem Summary -

IC receives Ed-Fi resources back from the ODS that are owned by different systems/vendors. They are then not able to delete or update these resources as we do not own them. When this happens, the best case scenario is that they are able to ignore the error all together as we did not have a need to try to delete or update the resource. The worst case scenario is that the error is thrown and the data is not updated, but it needs to be and now the data is incorrect at the state.

This issue is creating a lot of hits to the API that are unnecessary, it’s filling error logs with frivolous information, it’s creating confusion with our districts because they feel as though their data is not sending/updating correctly, and it’s preventing IC from being able to submit correct data to our states.

• When Campus makes a call to the ODS to retrieve a record and determine if a put, post, or delete needs to occur, AZ will return any resource that has the same natural key. The resource returned does not take key/secret into account so it will return a resource that was not even submitted by the requesting system’s key/secret. IC has seen this happen in the following scenarios:
  • AZ has some schools that are attended by students from many different districts. This school will set up their calendar and school to manage the enrollment for these students and send that information to the state. They are the ones that would own the calendar that is sent. Let's call this school ‘School A’. The districts where these students live (the residing district) will also set up the same school (School A) and calendar as they need to report the students to get the funding for them. In this scenario, the residing district would have a calendar with the same natural key as School A so AZ would return that residing district School A’s calendar resource. The residing district will then try to delete School A’s calendar to submit their own version of the calendar and will get an authorized error because they do not own the resource. This creates unnecessary errors as IC doesn’t actually want to delete School A’s calendar at all and would have preferred to never even see it.
  • Using the same exact scenario above, IC runs into problems when trying to update student information when the student moves mid-year. With this scenario, a student moves to a different residing district during the school year, but continues going to School A. With the move, the student’s address changes. The new residing district will enter the new address and try to send an updated Student Education Organization Association (SEOA) resource to the state so the state is aware of the new address. What should happen in this case is that the new residing district should send a brand new SEOA resource. However, AZ will return the SEOA from the original residing district and the new residing district will try to update that existing SEOA resource. When they do that, they get a not authorized error because they are not the owner of that resource.
  • Arizona and Wisconsin have taken different approaches on how to address this. Arizona has put the onus on us to manage it, but Wisconsin has implemented a way to not send data to a system/vendor unless that system/vendor owns it. We really need to have a general solution that would work for all states.
  • IC is looking forward to have a common solution:
    • One approach is to send the owner token back to the vendors
    • Not send the resources that the vendors don’t have access to.
    • GET calls don’t have restrictions.
  • Purpose of the working session is to discuss IC’s experience of receiving the resources owned by other systems/vendors in Ed-Fi and come up with a resolution of how to address this in a common way that would work for all states.
  • IC’s example: In AZ, private schools are not set up to send data for student resident district; public schools need to submit on behalf of private schools
    • Entity id, student enrollment, calendar
    • All districts across the state need to do this
    • When a private school student moves from 1 districts to another, the private school is set up twice; the result is that the second submission overrides the first submission and causes “not authorized” error messages
    • IC is unable to update student records. Work around authorization message/ignore error and not show it to the user.
    • Proposed solutions:
      • Give ownership token to the vendor via the API or
      • Restrictions on GETs like what WI did.
  • AZ
    • They will look into restriction on the GET
    • Report lists students shared by 2 districts
  • ODS team recognizes record level ownership problem
    • Phase 2 implementation - https://edfi.atlassian.net/wiki/pages/viewpage.action?spaceKey=EFTD&title=Phase+2+Implementation+Stories

Action Items:

• Aadi & Rohith - phase 2 implementation design methodology. AZ will see if they will be able to send the ownership token back to the vendors or put permission restrictions on GET calls.. 
• Eric and Sayee to discuss with Vinaya and report back any design that addresses this issue.
• Schedule follow up call in the next few weeks

Next meeting: TBD

Last Update: 14 Sep 2021