Jump to content

Join the future of EdTech

Moving data from point A to point B should be safe and easy - and with EduCloud it is! You get all the tools you need to take control over your data and see how and where it is shared in real time.

Sign Up
Search In
  • More options...
Find results that contain...
Find results in...

  • Articles

    Show all categories
    • Mikael Nilsson
      There have been some questions regarding how we in our SS12000 implementation will translate to the new duty roles. In the previous post we never mentioned the name fallbacks of the roles. We also have added more roles after the February article. In the PDF there is a more detailed explanation.

      Updated 2022-10-10 with new codes.
       
      Duty mapping YAML 2.1 20221010.pdf
    • Mikael Nilsson
      SIS released a version 2.1 of the YAML and a new version of the specification. This mostly targets discrepancies between the specification and YAML.
      We are currently working on updating to comply with the new requirements. The new changes are according to the versioning non-breaking but there are some changes to attributes that could cause problems if those attributes are in use (the change of spelling in variable titleEngish to titleEnglish) and if there are solutions that have tight restrictions on Enums (dutyCodes).
      We are planing to release this in the coming weeks and therefore just want to raise attention to the fact that this is in development.
    • Mikael Nilsson
      If you are a municipality sysadmin you can request a SS12000 keypair to be used for different vendors.
      To get a new key its only a few small steps to follow:
      1. Order the key thru the support portal
      2. The info you need to provide is 
      Wanted name of client municipalty.vendor is the usual name (e.g Norreka.istmatsedel) the municipality name is mandatory for the first part.
      The email address of the staff within the municipality who should receive the keypair (this keypair could then be sent to the vendor who should access the data)
      If you are a Educloud+ customer you also have the option of removing access for attributes/endpoints for the client. As Educloud+ customer you also have the option of login in into the dataviewer and selecting what units said client should be able to access. The options that can be removed today is
       
      ist.ss12000-v2.api.standard (organizational information, syllabus and programmes)
      ist.ss12000-v2.api.activities (activities information for the groups)
      ist.ss12000-v2.api.duties (the duties information for the teachers and personal information connected to the duty)
      ist.ss12000-v2.api.grades (grades for the students)
      ist.ss12000-v2.api.groups (group information)
      ist.ss12000-v2.api.placements (placements for the children)
      ist.ss12000-v2.api.responsibles (guardian information to connected enrolments)
      ist.ss12000-v2.api.students (the student information)
      ist.ss12000-v2.api.studyplans (the studyplans for the students)
      ist.ss12000-v2.api.email (the emails that is saved as main private email)
      ist.ss12000-v2.api.email-school (the teacher/student email)
      is12000-v2.api.phonenumbers (the phonenumbers saved on a person)
      ist.ss12000-v2.api.addresses (the addresses saved on a person)
      ist.ss12000-v2.api.photo (photos of the person)
      ist.ss12000-v2.api.civicno (the civic number of connected teachers/students/responsibles)
      ist.ss12000-v2.api.identifiers (externalidentifiers for the person)
      ist.ss12000-v2.api.sex (gender of the person)
      ist.ss12000-v2.api.birthdate (birthdate of the person)
    • Mikael Nilsson
      We have had some questions regarding the "experimental flags" that we mention in release notes. We have noticed that this needs a little deeper explanation.
      Why do we use them?
      When we have new features that we feel potentially could cause problems for users of our SS12000 implementation we try to set the changes to be kept under a flag so that the ones needing the changes can start using them and the ones that did not ask for changes have time to implement changes if it could effect their logic. These changes will then after some time be merged into the standard. 
      When we release something under experimental flag we write about it in the release notes or an article.
      How do get a flag turned on for my organisation?
      If the municipality wants this to be available for them the responsible for the municipality creates a support ticket to IST that they want the flag to be turned on.
      The current flags we have today are:
      newActivityLogic - This is a flag to make sure activities use a parent so that subjects like SO and NO can have multiple identifiable activities. studyplans - This enables the syllabus endpoint.  suppliers - This enables external organisations unmanagedAdmissions - This enables external admissions uuidsForTopNodeAndSupplierParent - This changes root id to a UUID and supplier root id to a UUID. useExtendedSchoolYearRangeForGroups - This enables getting active groups for next school year. These are added to new customers in Educloud as standard (still kept as flag for backwards comparability):
      useExtendedSchoolYearRangeForGroups newActivityLogic uuidsForTopNodeAndSupplierParent
    • Mikael Nilsson
      Our SS12000 implementation has been implemented with use of null values instead of removing attributes from payload when values are missing. This has been pointed out to us as breaking against the standard since the specification don't allow these values to be nullable. We will implement a change of this but want to give information about this as early as possible since it could cause problems for systems that rely on payload attributes always stay the same.  

      We have started to analyse the implications of changing this and will move forward with implementing a change.
      This example is from when a group don't have an endate
      Example:
      Previous payload when value was missing:

      "schoolType": "FTH",
      "startDate": "2022-04-22",
      "endDate": null,
      "reason": "Omsorg",
      Handling when the change will be implemented:
      "schoolType": "FTH",
      "startDate": "2022-04-22",
      "reason": "Omsorg",
       
       
    • Mikael Nilsson
      Mentioning this buggfix as an article pre-installation since this change might require developers to look at implementations to verify that there is no changes that affect systems after we roll out this change.
      But we have received bug reports about root level organisations (e.g customerId) not being UUIDs and thus breaking the SS12000 specification. This has been a known issue for a while but has been pushed since the customerId did not have an UUID connected to it and the potential downside of changing this can cause unwanted behavior in systems that have hard coded solutions for the ID at root level in the logic.
      We now have a UUID to connect the customerId and since we want to be compliant with the standard this will be rolled out soon.
      The change will be that before the ID in root level could be for example:
      SE00001
      It will now be for example:
      123e4567-e89b-12d3-a456-426614174000
      The external units id was previously always “supplier”
      That will be changed to a UUID aswell. The uuid will always be eb899bf3-5834-50e6-8b38-4cee6852db39
      This change will be used as experimentalflag on request in the beginning to not cause problems for users of API
    • Mikael Nilsson
      These changes will come out quite soon and will therefore be put under an experimental flag in the beginning for customers who want this change immediately. 
      After the change of allowing multiple activities connected to a group with different Syllabus it was noticed that the naming of the activity was wrong since all activities was named after group name, the activities names should be fetched from the Syllabus. This is now being fixed. 
      We previously did not have a need for parent activity, but after the change of allowing multiple activities it is sometimes needed to have a connection that is concluding all different syllabuses for schedule purposes. So this change also sets a parent activity that will keep the group name and which child activities point towards. 

       
       
    • Mikael Nilsson
      This is a small correction, school unit offering was not listed in not supported.
      Here is the latest pdf describing which fields we have in our SS12000 implementation. To read this document properly you need to check corresponding in the SS12000 YAML. A overview of that can be found here https://api.ist.com/ss12000v2-api/
      SS12000 supported fields 2022-03-01.pdf
    • Mikael Nilsson
      We are currently developing a change for the duty roles. The YAML for SS12000 only contained 6 roles ("Rektor", "Lärare", "Förskolelärare", "övrig pedagogisk personal", "förskolechef", "annan personal"). According to the specification document the roles should be aligned with Skolverkets API https://api.skolverket.se/vocab/common-terms/code-duty-role 
      We plan to map the duty codes with the new roles as following in the pdf.
      Duty mapping.pdf
       
    • Mikael Nilsson
      We have noticed that customers are having problems with groups connected to more than one activity. These groups are usually SO and NO groups. Today in our SS12000 implementation we only allow for one activity to be connected to one group, the group can't have multiple activities pointing to same group. We are changing this to allow more than one activity to be connected to the same group. 
       
      Previous solution:
        
       
      New solution being developed:

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. You can also read up on our Privacy Policy

  I accept