[Building Sakai] Can Sakai roles be mapped to LTI roles?

Steve Swinsburg steve.swinsburg at gmail.com
Wed Jan 22 15:31:44 PST 2014


You might be able to use this feature:
https://jira.sakaiproject.org/browse/SAK-24186

This allows incoming arbitrary roles to be mapped to Sakai roles.

cheers,
Steve


On Thu, Jan 23, 2014 at 10:10 AM, Schauer, Christopher R <
cschauer at txstate.edu> wrote:

>  Hi Lynn,
>
>  We implemented configurable role mapping for an attendance tracking LTI
> tool we wrote last year. We needed a way for the instructor to allow other
> roles (e.g. TA, Grader) to take attendance. What we did was add a rolemap
> property for the LTI tool that contains a comma-separated list of values of
> the form '<sakai role>:<LTI role>'.  The property can be added in
> sakai.properties or as part of the tool registration in IMSBLTIPortlet.xml.
> An example from our attendance tool registration:
>
>  <configuration name="imsti.rolemap"
> value="ta:TeachingAssistant,maintain:Learner/Instructor,access:Member,Guest:Learner/GuestLearner,Site
> Assistant:Instructor/GuestInstructor,Site
> Collaborator:Instructor/ExternalInstructor,Grader:TeachingAssistant/Grader"
> />
>
>  The mapped value will be used for the LTI role in the launch parameters
> and in the roster service. I will attach a patch to SAK-24185 with the
> changes we made and you can see if it will work for your use case.
>
>  -Chris
>
>  On Jan 22, 2014, at 9:40 AM, Charles Severance <csev at umich.edu> wrote:
>
>  Lynn,
>
>  While SAK-24185 is a valid use case, for me it has always been a low
> priority because tool providers seldom understand roles beyond Instructor
> and Learner anyways and things are pretty specialized.
>
>  My general approach is to send the *actual* Sakai role in this field:
>
> ext_sakai_role=CIG Coordinator
>
>  This way if a tool really wants to get tricky they can look at the exact
> role instead of a mapping which can get confusing or be mis-configured.
>
>  Others might write the code and I would not be opposed to it - but I
> don't plan on implementing SAK-2418 - because it feels too "Rube Goldberg"
> to me.
>
>  /Chuck
>
>  On Jan 22, 2014, at 10:09 AM, Stephen Marquard <
> stephen.marquard at uct.ac.za> wrote:
>
> Hi Lynn
>
>  I believe that is the use case expressed here:
>
>  https://jira.sakaiproject.org/browse/SAK-24185
>
>  Regards
>  Stephen
>
>
>  _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140123/24c8d1ef/attachment.html 


More information about the sakai-dev mailing list