fixing roles parameter in launch data

[ahmadio]

according to IMS Global
http://www.imsglobal.org/LTI/v1p1p1/ltiIMGv1p1p1.html#_Toc330273026

the launch parameter is roles not role which result in wrong assumption inside the Tool Provider side when I used it.

[auraz]

@Ahmadix thanks for your commitment! Please rebase on recent master, where role calculation was introduced.

[auraz]

for future LTI requests please do not hesitate assigning me or @olmar.

[ahmadio]

This is great @auraz I've just reviewed olmar additions, it seem to fix it regarding roles,
what about passing the user username to be displayed inside the TP, for example when using virtual meeting room it will be hard to distinguish different students

[auraz]

I think it is good idea, @Lyla-Fischer can we pass user name or alias?

[ahmadio]

If it possible also it is recommended to pass the context_title parameter which indicate "course title"
as it is documented here,
http://www.imsglobal.org/LTI/v1p1p1/ltiIMGv1p1p1.html#_Toc330273026

this would be great as will be good for archiving and referencing old activities in TP

[Lyla-Fischer]

Unfortunately, we cannot pass any non-anonymized user data to 3rd party providers using LTI integrations, so we cannot pass either user name nor alias.

However, we are planning on adding context_id (for course reference) and resource_link_id (for specific problem reference) in the near future.

[ahmadio]

can it be some kind of auto-generated aliases like "student123" and "instructor-3" etc. just to make some differentiation for a list of users that have to interact with each others on the other side i.e the tool provider?

[Lyla-Fischer]

We do not currently have any human-readable aliases. However, we do pass a different anonymous user_id to the LTI tool provider. If the tool provider wanted to auto-generate some random human-readable aliases and associate those aliases to the user_id's that the edX consumer passes, that seems perfectly reasonable.

The user_id that is passed to the tool provider does remain consistent from the point of view of the provider. There is not a method for the provider to connect the user_id that is receiving to an edX user account or edX user GUID without access to the data on the server hosting the OpenEdX instance.

[ahmadio]

I'm also thinking about a good solution that may require a bit more work, the solution is that every LTI component would prompt the user to enter his desired alias to be passed or asking his permission to pass his user name before launching the tool other wise passing an anonymized alias.

what do you think? @Lyla-Fischer

[Lyla-Fischer]

On a case-by-case basis, this is no better than the LTI provider just asking for an alias when an unrecognized user enters their tool.

It might be nice to provide some functionality to allow users to connect to some existing account on the 3rd-party service using the LTI provider, but that is a significantly more complicated set of functionality that is unlikely to land any time soon.

The thought might also occur that users should be able to determine their own settings for passing any edX-hosted data to 3rd party providers. However, 1) We don't have any method of setting user preferences like that at the moment and 2) We certainly don't have any method of setting app-specific preferences like that and 3) Users have no method of vetting the 3rd parties that authors determine to use in their course. Therefore, in order to protect edX users from their data being used in any unintended way or shared with unintended 3rd parties, we really can't enable that.

[sarina]

Hi @Ahmadix !

Thanks for the contribution! However, before we can merge your pull request, we need you to submit a signed individual contributor agreement, as documented in the CONTRIBUTING file in the repository. You should also add another commit to this branch where you add yourself to the AUTHORS file in the repository. Once you've done both of those things, we can review this PR.

@Ahmadix also, this branch will need a rebase because it has conflicts.

@auraz if you feel this code is safe to run on Jenkins, please run tests manually. If you do not know how to do this please ask me or test engineering on Hip Chat.

[Lyla-Fischer]

Just to clarify - Sarina (one of the edX Open Source community managers) was explaining some of the prerequisites to have edX reviewing this pull request at all. Alex and I kind of jumped the gun a little bit and started reviewing it early.

[ahmadio]

@sarina @Lyla-Fischer I think this PR need not to be merged as the issue was solved in another PR by Olmar that got merged, any way do you recommend to sign the agreement now for my further PRs?

[sarina]

@Ahmadix If this PR is unnecessary, please close it.

Follow the instructions in my poset to sign the contributor agreement so we can have it on file! You do not need to have an open pull request to sign the agreement. Read what I posted and follow the links :)

[ahmadio]

Alright, thanks :)
On Jan 31, 2014 11:11 PM, "Sarina Canelake" notifications@github.com
wrote:

@Ahmadix https://github.com/ahmadix If this PR is unnecessary, please
close it.

Follow the instructions in my poset to sign the contributor agreement so
we can have it on file! You do not need to have an open pull request to
sign the agreement. Read what I posted and follow the links :)

—
Reply to this email directly or view it on GitHubhttps://github.com/edx/edx-platform/pull/2220#issuecomment-33842826
.