Vad är centraliserade meddelanden?

Utveckling av centraliserade notifieringar

I Totara 14 introducerade vi ett nytt system för att generera notifieringar. Vi ändrade hur utvecklare skriver meddelandefunktioner i funktioner och hur användare konfigurerar och interagerar med meddelanden. I vår dokumentation hänvisar vi till denna funktion som 'centraliserade aviseringar'. Historiskt sett behövde utvecklare fatta många beslut om hur aviseringar skulle fungera, vilket resulterade i en inkonsekvent upplevelse för användare när det gällde att konfigurera och interagera med aviseringar. Det centraliserade notifieringssystemet ger utvecklare ett konsekvent sätt att implementera notifieringar och användare att använda dem.

Den första utgåvan av centraliserade notifieringar inkluderade migrering av program och certifieringsnotifieringar till det nya systemet. I efterföljande utgåvor har fler funktioners notifieringar lagts till i centraliserade notifieringar, medan andra fortfarande hanteras utanför det centraliserade notifieringssystemet och nu benämns ”legacynotifieringar”. När Totara avancerar kommer vi att fortsätta att migrera befintliga meddelanden och lägga till nya meddelanden till det centraliserade meddelandesystemet. Till exempel Totara 16 såg introduktionen av kursanmälningar, som hanteras via centraliserade notifieringar.

Centraliserade meddelanden förklarade

”Centraliserade notifieringar” är den term som används för det nya notifieringssystemet. Utvecklare lägger till funktionalitet till funktioner, så att användare kan konfigurera meddelanden som ska skickas i samband med händelser som inträffar. Det finns två olika typer av händelser som du kan konfigurera notifieringar för:

• Händelser kan vara åtgärder som en användare utför, till exempel när en användare slutför en kurs

• Händelser kan representeras av datum som registrerats i databasen, såsom ett förfallodatum för programmet

Utvecklare måste implementera en aviseringsutlösare för varje typ av händelse som måste resultera i en avisering. Till exempel kan en utvecklare implementera en meddelandeutlösare baserat på kursens förfallodatum. Användare kan sedan konfigurera valfritt antal notifieringar för varje notifieringsutlösare. Till exempel kan en kursadministratör skapa en avisering om ”På grund av sju dagar” samt en avisering om ”två dagar försenad”, båda baserat på samma aviseringsutlösare.

När en händelse inträffar kontrollerar det centraliserade meddelandesystemet för att se om några meddelanden är konfigurerade för att skickas. Det finns flera steg involverade i att bestämma vilka meddelanden som kommer att skickas, vem som kommer att få dem, vad innehållet kommer att vara och hur de kommer att levereras.

Fördelar med centraliserade notifieringar

Det centraliserade notifieringssystemet är ett standardsätt för utvecklare och slutanvändare att interagera med notifieringar. Här har vi beskrivit några av de viktigaste fördelarna med att använda centraliserade meddelanden:

• Meddelanden för en rad olika funktioner delar ett gemensamt gränssnitt. Tidigare tillhandahöll olika funktioner olika gränssnitt för att konfigurera notifieringar, med olika funktioner och konfigurerbarhet.

• Meddelanden kan återanvändas över mer än en instans (t.ex. samma meddelande i mer än en kurs). Tidigare implementerade olika funktioner olika sätt att dela mellan instanser, till exempel använda mallar.

• Användare har ett enda sätt att konfigurera alla sina meddelandeinställningar i det centraliserade meddelandesystemet. Tidigare kunde vissa notifieringar konfigureras i användarinställningar, medan andra var hårdkodade för att levereras via e-post, eller hade något annat konfigurationssätt.

• Beteendet för hur meddelanden skickas är konsekvent. Tidigare användes olika system för att avgöra vilka meddelanden som skickades och när. Det fanns olika sätt att hantera meddelanden som borde ha skickats tidigare, till exempel när ett nytt meddelande skapades för att skickas när en händelse inträffade, när den händelsen redan hade inträffat för vissa användare.

• Vid inställning av notifieringar har användare ett konsekvent sätt att välja vem varje notifiering ska skickas till. Tidigare, om ett meddelande behövde skickas till en användares chef, behövde en utvecklare implementera koden för att få det att hända, och anpassade gränssnittselement för att tillåta användare att kontrollera när den skulle användas.

• Ett delat schemaläggningssystem, som gör det möjligt att schemalägga nästan alla meddelanden, med minimalt arbete som krävs av utvecklaren. Tidigare var utvecklarna tvungna att implementera anpassade lösningar för att lägga till schemaläggning, inklusive gränssnittet som gjorde det möjligt för användare att konfigurera scheman.

• Ett enhetligt platshållarsystem, som möjliggör återanvändning av platshållare mellan olika anmälningstriggers, och en gemensam syntax för användare att använda platshållare i sitt meddelandeinnehåll. Tidigare var utvecklarna tvungna att implementera en anpassad lösning i varje funktion där platshållare krävdes, och användare var tvungna att lära sig rätt platshållarsyntax för den specifika funktionen.

• Konsekvent implementering av flerspråkiga funktioner. Tidigare var utvecklarna tvungna att implementera användningen av flerspråkiga funktioner i varje funktion med hjälp av notifieringar.

• En ny, enda källa för granskning av alla meddelanden och alla utgångstyper. Tidigare var användare tvungna att förlita sig på loggar som gjorts specifikt för en funktion, där det var tillgängligt, eller försöka använda interna varningar och uppgifter aviseringsdata som en källa för rapportering.

• Ett kärnsystem för utvecklare att implementera anmälningsutlösare på ett konsekvent och enkelt sätt. Mycket av arbetet med att utveckla anmälningsutlösare har gjorts för utvecklaren. Tidigare var utvecklare ofta tvungna att implementera sina egna lösningar på problem som schemaläggning och platshållare, men dessa tas alla om hand i centraliserade meddelanden.

Hur centraliserade notifieringar behandlas

Aviseringshändelser baserade på åtgärder och de som baseras på registrerade datum behandlas på något olika sätt:

När en meddelandehändelse hittas sker följande process:

1. Om aviseringsutlösaren är inaktiverad så kommer aviseringen att kasseras (detta kan faktiskt inträffa tidigare, men är inte relevant ur användarens synvinkel).

2. Om meddelandet är inaktiverat så kasseras det.

3. Meddelandeutlösaren kan implementera ytterligare villkor som måste uppfyllas innan meddelandet skickas. Händelsedata utvärderas och meddelandet kommer att kasseras om det inte uppfyller dessa kriterier.

4. Listan över mottagare beräknas baserat på händelsedata.

5. Meddelandeinnehållet genereras för varje användare. Platshållare i patienten och kroppen ersätts med värden som beräknas med hjälp av händelsedata.

6. Varje mottagares aktiverade utgångar beräknas.

7. Meddelandeinnehållet skickas via varje utgång för varje användare.

Särskild anmärkning om när meddelanden skickas

Tidigare implementerades olika notifieringar på olika sätt. Ett viktigt problem var hur systemet visste om ett meddelande hade skickats, vilket hjälpte till att avgöra om ett meddelande behövde skickas. I många fall, om ett nytt meddelande skapades av en administratör, skulle systemet avgöra att meddelandet inte hade skickats till ett antal användare som redan uppfyllde kriterierna för att ta emot det meddelandet, och skulle sedan skicka det meddelandet till dessa användare. I de flesta fall var detta inte det avsedda resultatet. I det centraliserade meddelandesystemet skickas meddelanden endast när de ska skickas. Meddelanden placeras inte i en kö som väntar på att levereras vid någon senare tidpunkt. Systemet söker inte efter meddelanden som missades eller borde ha skickats tidigare. Systemet förlitar sig på timing för att avgöra vad som behöver skickas vid varje given tidpunkt. Den frågar "Vilka meddelanden borde ha skickats mellan nu och sista gången som meddelanden skickades?" och endast dessa meddelanden skickas.

Ett exempel kan hjälpa till att förklara detta. Säg att du har skapat ett meddelande för att välkomna nya användare när de är registrerade på en kurs. Om aviseringen är schemalagd att skickas Vid händelse (dvs. så snart användaren är inskriven), så kommer den endast att skickas till användare som anmäler sig efter att du skapat aviseringen. Meddelandet kommer inte att skickas retroaktivt för användare som registrerade sig innan du skapade meddelandet. Om du ställer in samma avisering att skickas 1 månad efter inskrivning, så kommer systemet varje dag att kontrollera användare med ett inskrivningsdatum en månad tidigare, och kommer att skicka till dessa användare, även om aviseringen inte existerade när de anmälde sig. I detta fall kommer alla användare som registrerat sig under den senaste månaden, och de som registrerar sig i framtiden, så småningom att få meddelandet, på lämpligt datum. De som registrerade sig för mer än en månad sedan kommer aldrig att få det, eftersom de skulle få meddelandet innan det skapades.

Beskedsarv

Aviseringar i det centraliserade aviseringssystemet ärvs från högre kontexter till lägre kontexter. Med ärftlighet av aviseringar bör du vara medveten om att alla aviseringar som har inaktiverats i en kontext, då kommer de aviseringarna att vara inaktiverade och inte tillgängliga i de lägre kontexterna.

Exempelvis:

• Seminarieaviseringar är inaktiverade i ‘kategori A’ på kategorinivå.

Därför kommer seminarieaviseringarna inom ‘kategori A’ och i alla kurser, eller för alla aktiviteter under ‘kategori A’ att vara inaktiverade.

Notera: Inaktiverade aviseringar på webbplatsnivå inaktiverar alla aviseringar i alla kontexter. Aviseringar som inaktiveras på kategori- eller kursnivå kommer endast att inaktivera aviseringar i lägre kontexter under den kategorin eller kursen.

Funktionen som tillhandahålls av arv liknar idén med mallar, eftersom meddelanden kan skapas och hanteras på ett ställe och sedan återanvändas på många andra platser.

Meddelanden kan skapas i olika sammanhang, till exempel inom kurser, program, seminarier eller i systemsammanhang (kallas även ”platsnivå”). Meddelanden kan konfigureras i sammanhang som är högre än sammanhanget där händelsen inträffar och ärvs till lägre sammanhangsnivåer. Till exempel så sker kursavslutningshändelser i en kurskontext, men aviseringar om genomförd kurs kan skapas i systemkontexten, såväl som inom individuella kurser. Anmälningarna i vilket sammanhang som helst bestäms av de som skapats i det sammanhanget samt de som ärvts från högre sammanhang. Meddelanden i högre sammanhang ärvs i alla fallande sammanhang där händelsen inträffar.

Meddelanden som ärvs från högre sammanhang kan ha olika egenskaper åsidosatta i ett lägre sammanhang. Till exempel kan en deltagare som tilldelats i programmeddelande skapas i systemkontexten, med generiskt ämnes- och kroppsinnehåll som är lämpligt för de flesta program. Sedan i ett specifikt program kan ämne och kropp anpassas för att vara mer lämpliga för det programmet, eller så kan meddelandet inaktiveras helt i det programmet.

Du kanske till exempel vill att alla kurser på din webbplats ska skicka ett välkomstmeddelande när en användare först registreras. Detta meddelande ska ha samma innehåll i alla kurser, förutom namnet på kursen och namnet på användaren. I gränssnittet för meddelanden på platsnivå kan platsadministratören ställa in ett meddelande och inkludera kursens fullständiga namn och platshållare för användarens förnamn i ämnet och/eller kroppen (1). Detta meddelande kommer att ärvas i alla kurser, vilket innebär att alla nya och befintliga kurser kommer att få detta nya meddelande automatiskt inställt (2). I en viss kurs kan kursadministratören bestämma att meddelandetexten behöver ändras för att ge ytterligare information till nya användare. De kan ändra aviseringen på denna specifika kontextnivå genom att redigera den ärvda aviseringen inom kursens aviseringsgränssnitt, aktivera Åsidosätt toggle för meddelandetexten och göra de nödvändiga ändringarna (3). I en annan kurs kan kursadministratören välja att inaktivera den ärvda notifieringen och skapa en ny anpassad notifiering baserat på samma notifieringsutlösare (4).

Äldre version (legacy) av notifieringar

För närvarande använder ett antal olika funktioner äldre meddelanden, som fungerar annorlunda än det centraliserade meddelandesystemet. Om funktionaliteten du använder inte täcks av centraliserade notifieringar, kontrollera dokumentationen för den funktionen. Vi kommer att fortsätta att lägga till nya meddelanden och migrera befintliga meddelanden till det centraliserade meddelandesystemet .