LTI - Anpassade parametrar

  • Uppdaterad

Denna artikel innehåller en förklaring av alla de anpassade parametrar (custom parameters) som vi för närvarande stöder. Vissa LMS, som Moodle, tillåter konfiguration av anpassade parametrar på både verktygskonfigurationsnivå och på provnivå. Andra LMS, som Canvas, tillåter endast konfiguration av parametrar på konfigurationsnivå.

Om en anpassad parameter definieras på verktygskonfigurationsnivå kommer den att tillämpas på alla prov (som startas efter att den konfigurerats). Om den definieras på provnivå kommer den endast att tillämpas på provnivå. Om en anpassad parameter är definierad på konfigurationsnivå kan den inte ändras på provnivå.

Hur anpassade parametrar fungerar

För att LTI-integrationen med Inspera ska fungera som avsett kan extra data krävas för att varje institution ska kunna forma LTI-integrationen efter sina egna behov. Dessa extra data konfigureras med hjälp av anpassade parametrar. De skickas till Inspera varje gång en lärare startar verktyget (launch).

Endast LMS-administratören kan konfigurera anpassade parametrar på konfigurationsnivå. Dessa kan ändras när som helst och kommer att påverka alla framtida starter för alla prov (gamla som nya).

I vissa LMS kan lärare ställa in anpassade parametrar på provnivå och dessa kommer då endast att användas vid alla framtida starter av det specifika provet.

Om de inte ställs in är standardvärdet för alla anpassade parametrar false, vilket innebär att det endast är nödvändigt att konfigurera de anpassade parametrar som är relevanta för arbetsflödena vid din institution.

Viktiga anpassade parametrar

Det finns vissa anpassade parametrar som alltid bör konfigureras för att säkerställa korrekt funktion. Dessa bör konfigureras på verktygskonfigurationsnivå. Vissa av dessa är kanske bara relevanta för ett specifikt LMS, men de kommer inte att större ditt arbetsflöde. Du kan kontrollera var och en av dem för att få en bättre förståelse för vad de gör.

  • skip_incomplete_members = true (detta förhindrar avbrott i inskrivningen av bidragsgivare/studenter i händelse av fel)
  • use_template_on_create = true (endast för institutioner som arbetar med mallar och använder ett LMS som tillåter anpassade parametrar på provnivå)
  • Keep_test_title = true (relevant för institutioner som använder D2L).

Du bör också överväga:

Vanliga inställningar

  1. För att uppnå detta bör du använda den anpassade parametern:

    • enroll_candidates = true

    Om du vill att detta ska hända i alla prov i alla kurser, lägg till den i verktygskonfigurationen. Om du vill att detta endast ska hända i vissa prov, ställ inte in den på verktygskonfigurationsnivå och instruera dina lärare att ställa in den när de skapar provet där detta ska tillämpas (om LMS:et stöder det).

    Extra: om du vill att studenter som tas bort från kursen ska avregistreras från IA-provet, använd remove_candidates=true. Det är viktigt att notera att detta kommer att ta bort alla studenter som kan ha lagts till i provet direkt i IA om de inte är tillagda i kursen i LMS:et.

  2. För att uppnå detta bör du använda den anpassade parametern:

    • enroll_contributors = true

    Om du vill att detta ska hända i alla prov i alla kurser, lägg till den på verktygskonfigurationsnivå. Om du vill att detta endast ska hända i vissa prov, ställ inte in den på verktygskonfigurationsnivå och instruera dina lärare att ställa in den när de skapar provet där detta ska tillämpas (om LMS:et stöder det).

    Extra: om du vill att lärare som tas bort från kursen ska tas bort som bidragsgivare från IA-provet, använd remove_contributors=true. Det är viktigt att notera att detta kommer att ta bort alla bidragsgivare som kan ha lagts till i provet direkt i IA, om de inte är tillagda som lärare i kursen i LMS:et.

  3. I de flesta fall när SSO används är e-postadressen den unika identifieraren för användare. I så fall bör du lägga till konfigurationen:

    • username_resolver=BY_EMAIL

    Om den unika identifieraren är en annan måste du identifiera den korrekta och definiera den anpassade parametern username_resolver i enlighet med detta. För mer information, vänligen se dokumentationen om username_resolver under avsnittet användarsynkronisering.

    Du bör också identifiera rätt autentiseringstyp (auth type – t.ex. google, saml, etc.) för användaridentifiering. Detta kommer att vara samma som konfigurerades när IA-instansen sattes upp. När du har identifierat den, konfigurera den anpassade parametern:

    • lti_authtype=<samma auth type>

    För listan över tillgängliga värden, se avsnittet om denna anpassade parameter i avsnittet användarsynkronisering.

    Båda dessa anpassade parametrar måste definieras på verktygskonfigurationsnivå.

  4. Ja. Med den anpassade parametern candidateid_resolver.

    För att identifiera rätt värde för parametern (du kan se möjliga värden i avsnittet hantering av studenter), måste LMS-administratören identifiera den LTI-egenskap som innehåller studentens namn och/eller definiera candidateid_resolver i enlighet med detta. De kan sedan köra ett prov i felsökningsläge (debug mode) för att se de värden som skickas till Inspera.

    Till exempel, om det är e-post, bör det vara:

    • candidateid_resolver=BY_EMAIL

  5. Det kan finnas tre olika scenarier

    1. Användaren finns redan i IA och har minst de roller som krävs
      1. Användaren förblir oförändrad i IA
    2. Användaren finns redan i IA men har inte de roller som krävs
      1. De roller som krävs kommer att läggas till för användaren, de återstående roller de kan ha kommer att finnas kvar 
    3. Användaren finns ännu inte i IA
      1. En ny användare skapas i IA med de roller som krävs

    Detta händer antingen under lärarregistreringen eller när läraren startar provet genom LTI.

    De roller som krävs beror på mappningen mellan LMS- och IA-roller.

    Det finns två mappningar:

    • LTI - IA
      • LTI erbjuder vissa roller (som instructor) och dessa roller är mappade till rollerna i IA
      • Standardmappningen är instructor i LTI -> Författare (Author), Admin (Planner), Bedömare (Grader), Huvudvakt (Chief Invigilator) i IA
      • Om en annan mappning krävs, vänligen kontakta vårt supportteam. IA stöder inte mappning av underroller
    • LMS - LTI
      • LMS-administratören måste se till att LMS - LTI-mappningen är korrekt inställd så att LTI-rollerna sedan mappas till IA
      • Om LTI - IA-mappningen är standard, bör alla LMS-lärarroller mappas till LTI instructor-rollen
  6. Om två eller fler LMS är konfigurerade till samma IA-miljö (tenant), bör ett prefix definieras som är unikt för detta LMS. Detta bör konfigureras på verktygskonfigurationsnivå. Detta prefix kommer att läggas till som ett prefix till prov-id för att skilja mellan prov skapade genom olika LMS och det kan ha vilket värde LMS-administratören vill:
    • arid_prefix=<värde definierat av administratören>
  7. Om detta händer beror det troligen på att LMS-administratören konfigurerade samma anpassade parameter på verktygskonfigurationsnivå och den kan då inte åsidosättas. Kontrollera med dem. Om så inte är fallet, använd den anpassade parametern för felsökning (debug) för att verifiera vilka värden som skickas till IA. Om de aktuella värdena skickas men resulterar i ett felaktigt beteende, vänligen kontakta vår service desk.

Lista över anpassade parametrar

Kom ihåg att om de inte konfigureras, kommer alla anpassade parametrar som standard att vara false.

Hantering av bidragsgivare

enroll_contributors

  • Om false kommer inga bidragsgivare (förutom den aktuella användaren) att läggas till automatiskt i provet i IA. Men om en lärare klickar på länken till provet i LMS:et kommer de att skrivas in som bidragsgivare oavsett denna parameter.
  • Om true kommer användarna som lagts till som deltagare i kursen att automatiskt läggas till i provet i IA som bidragsgivare.

remove_contributors

  • Om false kommer borttagning av en deltagare från kursen i LMS:et inte att påverka provets bidragsgivare i IA.
  • Om true kommer en användare som lagts till som bidragsgivare i ett prov i IA, men som inte är (eller inte längre är) deltagare i kursen i LMS:et, att tas bort som bidragsgivare.

Hantering av studenter

enroll_candidates

  • Om false kommer inga studenter att skrivas in automatiskt i provet i IA.
  • Om true kommer studenterna som lagts till som deltagare i kursen att automatiskt skrivas in i provet i IA som studenter.

remove_candidates

  • Om false kommer borttagning av en student från kursens deltagarlista i LMS:et inte att ta bort motsvarande studenter från provet i IA.
  • Om true kommer en användare som lagts till som student i ett prov i IA, men som inte är (eller inte längre är) deltagare (som student) i kursen i LMS:et, att tas bort från listan över studenter i provet i IA.

Allmän användarhantering

skip_incomplete_members (denna bör alltid ställas in på true)

  • Om false kommer resten av studenterna/bidragsgivarna inte att skrivas in om ett fel inträffar vid inskrivning av en student eller en bidragsgivare.
  • Om true kommer användaren att hoppas över och inskrivningen fortsätta om ett fel inträffar vid inskrivning av en student eller en bidragsgivare.
  • Bör ställas in på verktygskonfigurationsnivå.

Användarsynkronisering med IA

Som förklaras i vår LTI-dokumentation sker två saker när en lärare startar ett prov via LMS:et:

  • Användaren loggas in i IA
  • Användaren skrivs in på provet 

Lärare som inte ska skrivas in på provet i IA bör inte klicka på länken till provet i LMS:et.

För att detta ska fungera är det nödvändigt att definiera det användarnamn (username) och det externa ID som ska associeras med denna användare i IA. Detta används när användarna skapas i IA (om tillämpligt) och för att identifiera en redan skapad användare.

Dessa används också när en användare vill logga in direkt i IA (inte via LMS:et).

Därför är det viktigt att säkerställa att användarnamn och external_id som skapas när användaren kommer från LMS:et är desamma som används när användaren får åtkomst till IA direkt.

Följande anpassade parametrar bör övervägas för att säkerställa en smidig användaridentifieringsprocess:

  • username_resolver
  • lti_username_externalid_suffix
  • lti_authtype

Alla dessa anpassade parametrar bör ställas in på verktygskonfigurationsnivå.

username_resolver

  • denna anpassade parameter definierar hur användarnamn och external_id för användarna i Inspera definieras
  • varje användarnamn måste vara unikt, så username_resolver bör säkerställa att inga användare hamnar med samma användarnamn
  • som standard är användarnamnet för- och efternamn och external_id är baserat på user_id och oauth_client_key
  • om standardkonfigurationen inte säkerställer användarnamnens unikhet måste en annan konfiguration väljas. Alternativ: BY_EMAIL, BY_SOURCEDID, BY_INSPERA_PROPERTY. För mer information om LMS-fälten som används, vänligen se tabellen inuti den utvidgningsbara sektionen

  • Följande tabell förklarar vilka fält från varje tjänst som används för att bygga external_id och användarnamnet.

    Värde för username_resolver Login Membership External_ID & Användarnamn
    DEFAULT

    user_id = user_id

    prefix kommer från den anpassade parametern lti_username_externalid_suffix 

    given_name = lis_person_name_given

    family_name = lis_person_name_family

    user_id =userId

    given_name = givenName

    Family_name = familyName

    external_id:  oauth_client_key+user_id+prefix

    användarnamn = given_name+family_name
    BY_USERID Samma som DEFAULT Samma som DEFAULT Samma som DEFAULT
    BY_EMAIL email = lis_person_contact_email_primary email = email

    external_id = email

    användarnamn = email
    BY_SOURCEDID source_id = lis_person_sourcedid source_id = sourcedId

    external_id = source_id

    användarnamn = source_id

    BY_INSPERA_PROPERTY

    Detta kräver två extra anpassade parametrar

    		 värde = inspera_property_lti_login värde = inspera_property_membership

    external_id = värde

    användarnamn = värde

    Hur man använder värdet BY_INSPERA_PROPERTY för username_resolver:

    • Detta gör det möjligt att använda valfritt fält från LTI login- och membership-tjänsterna.
    • De anpassade parametrarna inspera_property_lti_login och inspera_property_membership ska ställas in på motsvarande fältnamn.

    Exempel:

    • En användare vill använda det anpassade fältet ”ext_user_username” i login och ”ext_user_username2” i membership (påhittade namn). De ska ställa in de anpassade parametrarna som:
      • username_resolver=BY_INSPERA_PROPERTY
      • inspera_property_lti_login=ext_user_username
      • inspera_property_membership=ext_user_username2

lti_username_externalid_suffix

  • Används för att definiera suffixet för external_id som nämns i beskrivningen av username_resolver. Det är normalt något i stil med ”@exempel.se”.

lti_authtype

  • I IA kan vi ha olika sätt att logga in samma användare (GOOGLE, GENERIC_SAML, osv.). Det finns ett external_id kopplat till var och en av dessa. Dessa kallas internt för auth_type. Om det finns en specifik inloggning måste denna ställas in för att matcha den.
  • Standardvärde är LTI.
  • Möjliga värden: 'GENERIC_SAML', 'GOOGLE', ‘OIDC’, ‘SHIBBOLETH’.

  • I det här exemplet är både username_resolver=BY_EMAIL och lti_authtype=LTI inställda eftersom e-post är den unika identifieraren och oauth-typen är SAML.

    Nödvändiga steg:

    • Logga in på din Inspera-portal med SSO för att kontrollera fältet för externalUserId-mappning i saml-assertion. Samma fält måste mappas som externalUserId från Inspera och LMS. Använd en testanvändare för att identifiera attributet för e-postadress från SAML-tokenet. 

    • I webbläsarens utvecklarfönster, hämta SAML-responsen för assertion https://{domän}/saml/endpoint/assertion 

    • Avkoda SAML-responsen med valfritt SAML-verktyg. Den avkodade versionen bör likna följande: 

    • Inspera accepterar namnet ’urn:oid:1.3.6.1.4.1.5923.1.1.1.6’ eller det enkla namnet 'eduPersonPrincipleName' som standard för attributnamnet som innehåller externalUserId i SAML-responsen. (SAML-fältsreferens)
    • Om eppn (eduPersonPrincipleName) inte finns i SAML-responsen måste du lägga till detta i attributlistan i SAML-konfigurationen. Detta är fältet som kommer att användas för att mappa användaren mellan båda plattformarna – LMS och Inspera.
    • Som standard accepterar Inspera eppn som externalUserId. Om du vill använda ett annat attribut måste du informera Inspera om detta under SAML-inställningen. 
    • Om vi kan identifiera ett attribut i SAML-assertion som innehåller e-postadressen kan detta kombineras med username_resolver=BY_EMAIL. Detta fungerar om externalUserId är detsamma i Inspera och LMS. Att använda eppn med BY_EMAIL fungerar bara om eppn innehåller samma e-postadress som registrerats i LMS.

candidateid_resolver

  • När en student startar provet från LMS:et eller skrivs in via den anpassade parametern enroll_candidates, måste ett candidate_id skapas för att representera studenten på det provet. En student kan genomföra flera prov, men ett kandidat-ID måste vara unikt för varje prov.
  • Denna resolver anger hur candidate_id byggs i Inspera. Som standard visas user_id, men andra värden kan användas.
  • Det är viktigt att säkerställa att kandidat-ID:n är unika. Om det finns två eller fler studenter med samma kandidat-ID kommer endast den första att skrivas in på provet. Alternativa värden: BY_EMAIL, BY_NAME, BY_SOURCEDID, BY_INSPERA_PROPERTY. För mer information, se tabellen i den utvidgningsbara sektionen.

  • Följande tabell förklarar vilka fält från varje tjänst som används för att bygga candidate_id.

    Värde för candidateid_resolver  lti-login-parameter membership-name
    DEFAULT user_id userId
    BY_EMAIL lis_person_contact_email_primary email
    BY_NAME name name
    BY_SOURCEDID lis_person_sourcedid sourcedId
    BY_INSPERA_PROPERTY inspera_property_lti_login inspera_property_membership

    Hur man använder värdet BY_INSPERA_PROPERTY för candidateid_resolver:

    • Detta tillåter användning av valfritt fält från LTI login- och membership-tjänsterna.
    • De anpassade parametrarna inspera_property_lti_login och inspera_property_membership ska ställas in på motsvarande fältnamn.

    Exempel:

    • En användare vill använda det anpassade fältet ”cand_id” i login och ”cand_id_memb” i membership (påhittade namn). De ska ställa in de anpassade parametrarna som:
      • candidate_id_resolver=BY_INSPERA_PROPERTY
      • inspera_property_lti_login=cand_id
      • inspera_property_membership=cand_id_memb

Skillnad mellan LMS

arid_prefix

  • Om två eller fler LMS är konfigurerade mot samma IA-miljö (tenant), bör ett prefix definieras som är unikt för detta LMS. Detta bör konfigureras på verktygskonfigurationsnivå. Detta prefix kommer att läggas till som ett prefix till prov-id för att skilja mellan prov skapade genom olika LMS.
  • Bör ställas in på verktygskonfigurationsnivå.

Felsökning (Debug)

Om verktygskonfigurationen inte fungerar som avsett kan felsökningsläget slås på. Detta görs med den anpassade parametern debugview.

debugview

  • Om false fungerar kommunikationen mellan LMS och IA normalt.
  • Om true aktiveras felsökningsläget, vilket innebär att användaren kan se den begäran som skulle ha gjorts från LMS till IA. När felsökningsläget är på når begäran inte IA och kommer därför inte att ha någon inverkan på IA.

Provinformation

För de LMS som tillåter att anpassade parametrar definieras på provnivå är dessa de parametrar som kan användas. Det är möjligt att definiera viss information gällande IA-provet i LMS:et via vissa anpassade parametrar.

inspera_test_start_time och inspera_test_end_time

  • Definiera start- och sluttid för provet. De måste vara en tidsstämpel i ISO-format (t.ex. ”2023-09-06T21:04+02:00” eller ”2023-09-06T19:04Z”).
  • Om de inte är inställda behöver de ställas in i IA innan provet aktiveras.

keep_test_title (denna bör alltid vara inställd på true)

  • Om false kommer namnet på provet i IA att ersättas med det som kommer från LMS:et.
  • Om true ändras inte namnet på provet i IA. Detta behöver användas i de fall LMS:et inte skickar titeln vid varje start (t.ex. D2L).
  • Bör ställas in på verktygskonfigurationsnivå.

lti_candidate_extratime

  • Ställer in extratid i minuter för alla studenter.
  • Standardvärde är 0.

assessment_path_parent

  • Om true kommer provet i IA att skapas som ett Vurderingsforløp (Assessment Path).
  • Om ett id skickas måste det vara id för det Vurderingsforløp-prov under vilket detta prov ska skapas, t.ex. om url:en för att få åtkomst till huvudprovet för vurderingsforløpet är https://namn.inspera.com/admin#deliver-test/97539878, då är id:t 97539878.

lti_test_template

  • Om false är provet som skapas i IA inte baserat på en mall.
  • Om id skickas bör det vara id för den mall som provet ska baseras på, t.ex. om url:en för att få åtkomst till mallen är https://namn.inspera.com/admin#deliver-test/97539878, då är id:t 97539878.

use_template_on_create (denna bör alltid vara inställd på true för att förhindra att läraren glömmer det vid användning av mallar)

  • Detta spelar bara roll om lti_test_template användes. Att definiera den för andra prov har dock ingen inverkan.
  • Om false kommer alla ändringar att skrivas över av mallvärdena varje gång provet startas från LMS:et.
  • Om true används mallvärdena endast när provet skapas vid den första starten.
  • Bör ställas in på verktygskonfigurationsnivå för att undvika att lärare glömmer bort det.

Var denna artikel till hjälp?

0 av 0 tyckte detta var till hjälp