member_status.tex

   1 \documentclass[12pt,a4paper]{article}
   2 \usepackage[nolists,nomarkers]{endfloat}
   3 %\usepackage[english]{babel}
   4 \usepackage{textcomp}
   5 \usepackage[utf8x]{inputenc}
   6 \usepackage[T1]{fontenc}
   7 \usepackage{color}
   8 \usepackage{graphicx}
   9 \usepackage{chngpage}
  10 \usepackage{ifthen}
  11 \usepackage{gitinfo}
  12 %\enabledraftstandard
  13 \usepackage[hidelinks]{hyperref}
  14 \usepackage{url}
  15 \usepackage{breakurl}
  16 \usepackage{xcolor,soul,lipsum}
  17 \usepackage{lineno}
  18 %\usepackage{adjustbox}
  19 %\usepackage{fancyvrb}
  20 %\usepackage{verbatim}
  21 \usepackage{rotating}
  22 \usepackage{listings}
  23
  24 \newcommand{\myul}[1]{\ul{#1}}
  25
  26 \usepackage[firstpage]{draftwatermark}
  27 %\SetWatermarkText{ENTWURF}
  28 \SetWatermarkText{DRAFT}
  29 \SetWatermarkScale{4}
  30 \SetWatermarkAngle{50}
  31 \SetWatermarkLightness{0.90}
  32
  33 \sloppy
  34 %\hoffset-3mm
  35 \parindent0mm
  36
  37 \newcommand{\da}{DA}
  38 \newcommand{\sa}{SA}
  39 \newcommand{\ecs}{ECS}
  40 \newcommand{\ilias}{ILIAS}
  41 \newcommand{\cces}{\texttt{cc/enrolment\_status\ }}
  42 \newcommand{\ccms}{\texttt{cc/member\_status\ }}
  43 \newcommand{\button}[1]{\fbox{\texttt{#1}}}
  44 \newcommand{\jsToAppletComUrlA}{\mbox{http://stackoverflow.com/questions/7278626/javascript-to-java-applet-communication}}
  45 \newcommand{\jsToAppletComUrlB}{\mbox{http://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html}}
  46 \newcommand{\appletToDom}{\mbox{http://docs.oracle.com/javase/tutorial/deployment/applet/manipulatingDOMFromApplet.html}}
  47
  48 \lstset{basicstyle=\ttfamily}
  49 \newcommand{\includecode}[2][{}]{\lstinputlisting[numbers=left, numberstyle=\tiny, stepnumber=1, numbersep=5pt, breaklines, breakatwhitespace, linewidth=1.1\textheight, xleftmargin=1cm, language=#1]{#2}}
  50
  51 \newcommand{\texta}{}
  52 \newcommand{\textb}{}
  53 \newcommand{\textc}{}
  54 \newcommand{\textd}{}
  55 \newcommand{\texte}{}
  56 \newcommand{\textf}{}
  57
  58 \linenumbers
  59
  60 \begin{document}
  61 \title{Mahara/Moodle member status}
  62 \author{David Boehringer\\Universit\"at Stuttgart \and Heiko Bernl\"ohr\\FreeIT.de}
  63 \maketitle
  64 \thispagestyle{empty}
  65 \begin{center}
  66 %  Version: 2.0
  67   Version: \gitVtag\\
  68 %  Commit-id: \gitAbbrevHash
  69 \end{center}
  70 \begin{abstract}
  71 New ECS resource providing enrolment status for users enroled to
  72 external courses (via courselinks). The course providing participant (e.g.
  73 Moodle) informs the courselink providing participant of the subscribed user
  74 (e.g. Mahara) about every change of its enrolment status in the course.
  75 This paper only concerns about informing a courselink providing system about
  76 status changes of their users consuming a course on a course providing system.
  77 As Stefan Meyer (ILIAS, Leifos) has noticed, this resource could also be used
  78 to inform about status of some more resources, e.g. ILIAS groups. In order to
  79 respect this we have generalized our naming of the resource name from \cces to
  80 \ccms and also the used attribute names. But all other details, especially the
  81 sequence diagrams and state chart only focus on courselinks and courses.
  82 Further we use Mahara as a courselink and Moodle as a course providing system.
  83 Of course these systems could be substituded by other system types.
  84 \end{abstract}
  85
  86 %\vspace{\fill}
  87 %\begin{center}
  88 %\includegraphics[scale=1.0]{vip_lms}
  89 %\end{center}
  90 %\vspace{\fill}
  91 %
  92 \newpage
  93
  94 \section{Member status}
  95
  96 The \ccms resource describes an enrolment status of a
  97 remotly subscribed user (via courselinks) to a course. This document supersedes
  98 the part
  99 \begin{quote}
 100   {\bf Moodle}\\
 101   1. New enrolmentStatus resource
 102 \end{quote}
 103 in \cite{specBoehMaharaMoodle}.
 104
 105 \subsection{Events\label{events}}
 106 \newcommand{\rstat}[1]{return status: #1}
 107 For the following event considerations please have always the state chart on
 108 page \pageref{state:enrolmentStatus} in mind.\medskip
 109
 110 Moodle has to send the user enrolment status to Mahara on these events:
 111 \begin{description}
 112   \item[first time clicking courselink] A user clicks on a courselink on Mahara
 113     for the first time and tries to consume the linked course on Moodle (sequence
 114     diagram on page \pageref{seq:initialEnrolmentStatus}).\\
 115     \rstat{active | pending }
 116   \item[reject] User will be rejected by course or system admin. This could only happen
 117     in \textit{pending} state, e.g. user was on a waiting list, but had not been
 118     accepted for the course.\\
 119     \rstat{rejected}
 120   \item[subscribe] User will be subcribed to course (leaving waiting list). Now
 121     he is able to access and consume the course.\\
 122     \rstat{active}
 123   \item[waiting list] User will be transfered to waiting list
 124     i.e. he can't access and consume the course yet. He has to wait until
 125     he will be subscribed to the course.\\
 126     \rstat{pending}
 127   \item[unsubscribe] User ended course membership himself or his course
 128     membership has been terminated by course administrator or system
 129     administrator. To access and consume the course again he has to enrole
 130     again.\\
 131     \rstat{unsubscribed}
 132   \item[disable subscription] User is disabled by course or system
 133     administrator, i.e. he is (temporarly) not allowed to access course for
 134     whatever reason.\\
 135     \rstat{denied}
 136   \item[enable subscription] User is enabled by course or system administrator,
 137     i.e. he is to be allowed to access course again.\\
 138     \rstat{active}
 139   \item[delete user account] User account on remote system is deleted. \ccms
 140     has to be sent for all of the user's course memberships.\\
 141     \rstat{unsubscribed}
 142   \item[deactivate user account] User account on remote system is deactivated.\\
 143     \rstat{inactive\_account}
 144   \item[activate user account] User account on remote system is activated.\\
 145     \rstat{active | pending | denied}
 146   \item[subsequently clicking courselink] A user subsequently clicks a
 147     courselink on Mahara and consumes an already enroled course on Moodle (see
 148     page \pageref{seq:subsequentEnrolmentStatus}).  After this event Moodle has
 149     to send the current enrolment status.  This also guarantees to have a
 150     status even if Mahara just forget/loose\footnote{We don't make the resource
 151     persistent,  so loosing the status somehow on Mahara it will be refreshed
 152     after next click on a courselink.} it somehow.\\
 153     \rstat{pending | active | denied }
 154 \end{description}
 155
 156 \subsection{Status values\label{statusValues}}
 157 \newcommand{\statusnotstored}{This status is usually not persistently stored in the LMS.}
 158 For the following status considerations please have always the state chart on
 159 page \pageref{state:enrolmentStatus} in mind.\medskip
 160
 161 The status attribute could have following values:
 162 \begin{description}
 163   \item[active] User is enroled and allowed to consume the course.
 164   \item[pending] User enroled for the course, but is on a waiting list.
 165   \item[rejected] User is not on waiting list anymore\footnote{Clicking the courselink
 166     again the user will get through initial enrolment as described in sequence
 167     diagram on page \pageref{seq:initialEnrolmentStatus}.}. \statusnotstored
 168   \item[unsubscribed] User is not enroled
 169     anymore\addtocounter{footnote}{-1}\footnotemark. \statusnotstored
 170   \item[denied] Still enroled but not allowed to access the course.
 171   \item[inactive\_account] Still enroled but temporarly not allowed to access
 172     the system.
 173 \end{description}
 174 Whereas only \texttt{active, pending, rejected} and \texttt{inactive\_account}
 175 status values have to be stored/saved on the LMS. All others are only generated
 176 while the transitions.
 177
 178 \subsection{Redirect querystring parameters\label{subsec:redirect_querystring_parameters}}
 179
 180 Our present specification of redirecting a user is defined in
 181 \cite{specRedirectProcedure} and the procedure how to compute the redirect hash
 182 (for securing the redirect parameters) in \cite{specHashCumputing}. As
 183 described in the document \cite{specBoehMaharaMoodle} Moodle has to provide an
 184 interface to define for each participant and its community participation what
 185 personal data should be appended as query strings. Of course to allow this we
 186 have to enhance our specs in \cite{specRedirectProcedure} and
 187 \cite{specHashCumputing}. This still needs to be done.
 188
 189 \begin{figure}[p]
 190   \vspace*{-1cm}\includegraphics[scale=0.8]{enrolment_status_seq}
 191   \caption{\label{seq:initialEnrolmentStatus}Sending enrolment status after
 192   consuming a courselink for the first time. For \textit{params} in
 193   the \textit{redirect} of the \textit{consume courselink} block  see
 194   \ref{subsec:redirect_querystring_parameters} at page
 195   \pageref{subsec:redirect_querystring_parameters}.}
 196 \end{figure}
 197
 198 \begin{figure}[p]
 199   \includegraphics[scale=0.8]{subsequent_enrolment_status_seq}
 200   \caption{\label{seq:subsequentEnrolmentStatus}Sending enrolment status
 201   after subsequently consuming a courselink.}
 202 \end{figure}
 203
 204 \begin{figure}[p]
 205   \centering
 206   \includegraphics[scale=0.5]{enrolment_status_state}
 207   \caption{\label{state:enrolmentStatus}UML state diagram. Enrolment status of
 208   a user in respect to a course on a LMS. For event description see
 209   \ref{events} on page \pageref{events}. For status values description see
 210   \ref{statusValues} on page \pageref{statusValues}.}
 211 \end{figure}
 212
 213
 214 \subsection{Resource attributes}
 215
 216 For the json schema of \ccms see page \pageref{schema:member_status}.
 217 Following description write on \ccms resource attributes for which a user
 218 status has changed or asked for:
 219 \begin{description}
 220   \item[url] It's a url transfering a courselink consuming user
 221     directly to the course on the course providing system. It could be used as a
 222     unique id.
 223   \item[id] It's a unique course id on the course providing system. It
 224     references the same course as \texttt{url}. It could be used as a unique id.
 225   \item[personID] Unique id of the course consuming user.
 226   \item[personIDtype] Class/type of \texttt{personID}. It's a controlled
 227     vocabulary (see page \pageref{schema:member_status} for possible
 228     values).
 229   \item[status] Status of the user's course enrolment. It's a controlled
 230     vocabulary (for possible values see schema on page
 231     \pageref{schema:member_status} and values descriptions at
 232     \ref{statusValues}).
 233 \end{description}
 234
 235 \subsection{PersonID types}
 236
 237 \begin{description}
 238   \item[ecs\_ePPN] EduPersonPrincipalName as defined in \cite{eppn}
 239   \item[ecs\_loginUID] Organization wide user id (uid in university context).
 240     Usually this would be the string in front of the `@' of the ePPN.
 241   \item[ecs\_login] Login name on course providing system (e.g. LMS). Only unique
 242     in connection with the LMS.
 243   \item[ecs\_uid] Internal user id on course providing system (e.g. LMS). Only unique
 244       in connection with the LMS.
 245   \item[ecs\_email] Email address.
 246   \item[ecs\_PersonalUniqueCode] SchacPersonalUniqueCode (matriculation number)
 247     as defined in \cite{SchacPersonalUniqueCode}. Should be used as values in
 248     order to be internationally compatible.
 249   \item[ecs\_custom] For local customized person id type.
 250 \end{description}
 251
 252 Across institutions a person identifying attribute should be used that is also
 253 used in context of eduGAIN interfederations such as `eduPersonPrincipalName'
 254 (ePPN); see eduGAIN Policy Framework Attribute Profile, p. 4.\medskip
 255
 256 Often these attributes are not used yet, but in context of eduGAIN federations
 257 (e.g. using Shibboleth) they are meant to be used to identify a remote user.
 258 Directory services or IdPs should be able to provide such a unique person
 259 identifying attribute. If they can, it must be stored as person data in the
 260 LMS. If necessary, the LMS has to be adapted to store such an attribute that is
 261 different from the UID of the user in his institution. Since the attributes are
 262 needed for eduGAIN compatibility of an LMS it is recommended that this is
 263 included in the core of the system and not as part of a plugin.
 264
 265 \begin{sidewaysfigure}[p]
 266     \includecode{cc_member_status.schema.json}
 267     \caption{JSON-Schema definition of enrolment\_status resource}
 268     \label{schema:member_status}
 269 \end{sidewaysfigure}
 270
 271 \begin{thebibliography}{99}
 272 \bibitem{specRedirectProcedure} \url{http://freeit.de/documents/ecsa/index.html#_redirect_procedure_protocol_when_consuming_courselinks}
 273 \bibitem{specHashCumputing} \url{http://freeit.de/documents/ecsa/index.html#_courselinks}
 274 \bibitem{specBoehMaharaMoodle} David Boehringer. \textit{Mahara and Moodle Specification Version 03}
 275 \bibitem{eppn} \url{http://middleware.internet2.edu/eduperson/}
 276 \bibitem{SchacPersonalUniqueCode} \url{http://www.terena.org/activities/tf-emc2/schacreleases.html}
 277 \end{thebibliography}
 278
 279 \end{document}