Passing group membership to external tools

Passing group membership to external tools

by Tim Hunt -
Number of replies: 13
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I am pretty much an LTI novice, so please excuse me if that is a silly question.

Is there a way to pass information about Group membership to the external tool?

I just found a 2014 thread from this forum: https://moodle.org/mod/forum/discuss.php?d=262855. The two tracker issues mentioned there were both fixed in Moodle 3.0, so I think that means the answer is 'Yes, if you can work out how to set it up'.

But - and this is probably the silly question - would be be possible to have a simpler option. For example, in the mod_lti setting, an option to be able to turn on Separate/Visible groups, and then the group info is included in the LTI launch? (Is there space for that in the LTI standard?)

Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Well, reading the code, I have found Moodle.Person.userGroupIds which looks like something that can be used in the Custom parameters - except that I cannot find any documentation about it, and I have not made it work yet.
Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Right, so in 'Custom parameters' you put somethign like

groupids=$Moodle.Person.userGroupIds

and then in the LTI launch you get something like:

custom_groupids: 123,456

(This is with LTI 1.1.)
Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
And, this returns all the user's group ids in this course.

I think that for what we are trying to do it would be better if:
  •  mod_lti said it supported FEATURE_GROUPINGS in lti_supports, so you could limit a particular LTI activity to the groups in one grouping.
  • Then Moodle.Person.userGroupIds used groups_get_all_groups($cm->course, $userid, $cm->groupingid) to get the list of relevant groups.
If this makes sense, let me know, and I will create a tracker.

Also, depending on how you are trying to integrat, group id may not be very useful. Extending this so it also supports Moodle.Person.userGroupNames and Moodle.Person.userGroupIdnumbers might be good.
Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Tim,

It's a little hard to guess what you're trying to achieve, but I'll post some general information in the hope it may be of some use to you.

There is an existing LTI specification called Course Groups which you can see listed here (https://www.imsglobal.org/activity/learning-tools-interoperability). You'll need to be signed in to IMS to see the spec though. This is an LTI Advantage service. We also already have an issue in Jira scoped with adding support for this here: https://tracker.moodle.org/browse/MDL-69233

Essentially, that allows the tool, via the Names and Roles service to ask the platform for information about the groups, groupings and group memberships.

Also, just a FYI - It's unlikely we'll pursue any modifications to LTI 1.1 code now, given that's no longer supported by IMS and we're unable to certify for that standard any more. The focus will be on adding these kinds of things to 1.3.

Cheers,
Jake
Average of ratings: -
In reply to Jake Dallimore

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
What we are trying to achieve is passing the information about which teacher is mentoring which students in this particular activity, to an LTI 1.1 tool.

In a course with multiple groupings, it would definitely be helpful to be able to select one grouping to apply to this LTI activity. That is a Moodle-side concept, so should not cause problems with standards compliance. Also, you probably want that as part of the 1.3 changes, if not before.

The Moodle.Person.userGroupIds thing is self-evidently a Moodle-specific add-on - which seems to be allowed within the spec, so why would extending that slightly cause you problems.

When you say "It's unlikely we'll pursue any modifications to LTI 1.1 code now" I realise you won't be making changes, but are you saying that if I made a patch, you are likely to reject it? Thanks for clarifying.
Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Thanks for clarifying, Tim.

I see a few options here

1. Extend the substitution vars, adding support for the field you want (the group's teacher- however that's calculated)
2. Write an LTI source plugin, which implements the hook ltisource_PLUGINNAME_before_launch, allowing you to send whatever you'd like in the custom params during launch.
3. I don't think it's worth looking into the membership service for 1.1 as this doesn't return groups with Moodle.

I think if you head down the path of substitution params (custom launch params), it's likely not going to be something we can land in core. You're probably going to end up with a specific param to give you the information you want (mentor details for a given student's launch), and this won't offer any value to the 1.3 side of things (which is what we are focusing on moving forward). Extending/adding substitution params (which are used by both 1.1 and 1.3) isn't generally a problem, provided they offer benefit/improvement to 1.3. If they happen to provide benefit for 1.1 in the process, then that's a plus. What I don't want is to be introducing substitution params which are only present as a workaround for something that LTI 1.3 and its services provide natively.

Ditto goes for the source plugin, it's not likely to be something core will use but it is an option nonetheless.

I agree that the groups/groupings feature support would be needed for that course groups service issue, if not before. That is, it doesn't make sense to talk about syncing groups and memberships when the module doesn't support that in the Moodle-feature sense (at least I don't think it does).

Re 1.1 and our policy, that is hard to answer definitively. It's a little tricky in mod_lti, given the nature of the code in there. What I mean by this is that we have a mod which deals with several versions of LTI launches. In some cases, a code change will only impact 1.1/2.0 and in others (like the cases you mention above with substitution params) we see it can impact several versions. We're certainly steering clear of any 1.1-specific changes now that 1.1 is deprecated at IMS, but changes like small extensions to substitution params would certainly be ok, since they improve things for 1.3, and are something I consider safe for 1.1 (substitution vars being a very easy thing to test, with low chance of breaking anything).

Hope that helps,
Jake
Average of ratings: -
In reply to Jake Dallimore

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Thanks for that very full reply, Jake.

I am about to disappear on holiday for a week, so no coding will happen before that.

I might at least create the tracker issue for adding FEATURE_GROUPING support to the plugin, because that is something that seems like a sensible quick win to me. (Although, as an improvement, it would need to land in 4.0.)

I may look at doing what we want in a ltisource plugin. (And, actually, if I made an ou-specific plugin, I would not need any core changes. I guess. I could hard-code some groups logic.) Do you know any examples of a really simple plugin? The ones at https://moodle.org/plugins/?q=type:ltisource look complex.

(By the way, I don't know why the tool I am being asked to integrate with is using LTI 1.1, but I am not responsible for that other tool. I am just trying to configure our Moodle to talk to it.)

Thanks again.
Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Hi Tim,

Creating the tracker for the groups/grouping feature wouldn't be a bad idea. I suspect the tricky thing there will be showing exactly how that feature is used by the external tool instance, in order to progress the issue through integration. Without the course groups service work, there isn't really anything being exchanged with the tool given this feature is supported. I guess you could set a grouping on the activity, but it wouldn't have any impact without other third party code right now. Do you see that issue having a wider scope? Perhaps enough to progress on its own?

Regarding the LTI source plugins, unfortunately I only know of those plugins that you can see on the plugins database.

I think there are still a number of tools still stuck on 1.1 at the moment. We're not likely to drop the ability to launch these for quite some time.

Cheers,
Jake
Average of ratings: -
In reply to Jake Dallimore

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I think that exposing all the groups defined in the current course to the external tool is potentially a privacy concern in some situtations. To give just one example.

Suppose you have a particular grouping in your course, with some groups you use to allow certain students additional time in the course quizzes using Group overrides. For that grouping, which students are in which group is senstive, and should not be sent to a third-party tool.

So, the point of Moodle's Grouping setting, is to say that, for this activity, only the groups in this particular grouping are relevant. I think it makes sense that for LTI, you can set that setting in Moodle, and then only the groups in that grouping are shared with this instance of the external tool. (It is like the other settings which let you control which information from this Moodle site gets shared to the other tool.

Does that make sense?
Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
I think that makes sense. Setting a grouping on the activity like this would appear to suggest similar Grouping behavior to the assignment module in that a student will be unable to participate in the activity unless they are present in one of the groups within the grouping. What I was more getting at,

I'll just type it out so I'm sure we're talking about roughly the same kind of thing.

So, in your example, while certain students are clearly in groups (and a grouping perhaps) denoting the need for extra quiz time, we can prevent these groups being sent to the tool by setting a grouping on the external tool - a grouping that doesn't include these special sensitive groups. Is that right?

We'd still have a means to allow all users to participate in the tool too. It's possible (likely?) that the students in these 'extra time' groups are in other course groups as part of a wider class grouping. If we were to set the external tool settings to use this wider course grouping, then only the 'non-sensitive' (for lack of a better term) groups will be exchanged with the tool (either as part of the course groups service work, as as part of your custom work for LTI 1.1). All students will still have access to the activity. I think I've got that right but please correct me if I've missed something there.

Then, providing the above is correct, we also need to make sure that the external tool knows what to do in cases where the student is NOT a member of any of the groups within the set grouping. In these cases, I think the activity should stop the user from being able to launch, similar to the way that the assignment blocks submissions for users outside the set grouping.

The next logical to then consider would be the membership service. We'll want to be sure that requests for membership return only those members in the set grouping. This would be similar to the way we don't return members who don't have access to the activity, I guess.

None of this causes me great concern for 1.1 because if a grouping isn't set, we just continue to exhibit the same behavior as we currently do.
Average of ratings: -
In reply to Jake Dallimore

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
"Is that right?" - yes. "I think I've got that right" - yes.

The only bit I am not sure about is "where the student is NOT a member of any of the groups within the set grouping. ... I think the activity should stop the user from being able to launch". I am not sure that we need to hard-code this logic. (and it might be problemmatic, because it would prevent an admin - not in any group in the course - from clicking the link to check it works.

However, the real reason we don't need to hard-code anything there is because, if you want that functionality, you can get it with the standard Moodle 'conditional availability' settings. By the way, what happens now if you click an LTI launch link as admin, is that $Moodle.Person.userGroupIds is just an empty string, which I think is perfectly reasonable.

I have created MDL-72421.
Average of ratings: -
In reply to Tim Hunt

Re: Passing group membership to external tools

by Jake Dallimore -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Thanks, Tim. Triaged that one just now.

I've had a look at how other modules implement support for this and I'm now leaning towards with what you just said about being permissive. In fact, my assign example was bad anyway as that was in the case where group submission was enabled.

If you just set a grouping on the assignment, even in separate groups mode course, anyone can submit to the assignment. It's only when filtering the submissions in the report that you're unable to filter on groups outside the set grouping.

A few example cases:
- Survey: Anyone can take the survey. Teachers then see a nice error message in the results report when trying to view a non-grouping submission (bug).
- Choice: anyone can answer, but teachers can't filter on groups outside of the set grouping.
- Assign: anyone can answer, but teachers can't filter on groups outside of the set grouping.
- Forum: Won't let you create a discussion unless you belong to the grouping.

So, it seems we're not 100% on how we implement this (e.g. forum blocks users who are from groups outside the set grouping). Being permissive and only including the group information from users within the set grouping seems to align with at least a few of the other cases above.
Average of ratings: -
In reply to Jake Dallimore

Re: Passing group membership to external tools

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Thanks Jake.

I think the issue with Forum is that when the forum is set to group mode, each post has to have a groupid set in the database or, to put it another way, it is like there is a sub-forum for each group. So, if you are not in a group in the relevant grouping, there is no sub-forum for you to post to, so it makes sense that you cannot post.
Average of ratings: -