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

[Ward, Lynn E.]

Thanks, Chris.  This is exactly the kind of approach I was imagining.

Sent from my iPad

On Jan 22, 2014, at 6:10 PM, "Schauer, Christopher R" <cschauer at txstate.edu<mailto: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<mailto: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<mailto: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<mailto: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<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org<mailto: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<mailto: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/20140122/a175c48d/attachment.html