Self-assigned cohorts

Hello community!

I perused the docs and failed to find a way to let learners self-assign into a cohort.
It’s for an open course which is tailored for two different target audiences, which would run for two or three years without supervision, hence the need to automate cohort assignment without admin intervention.

Is this feature unavailable in open edX?
Is there an add-on feature that could do it?

I am thinking of breaking up the course in two clones tailored for one audience each as a backup option.

Hi Vincent - I’ve always wanted a way to allow self-cohorting in MOOCs and the closest option has been to create Teams… Hopefully there is an add-on in the Open edX world.

3 Likes

Sorry I’m just seeing this after 4 months. We built a cohort selector block a while back for this purpose.

It’s a few versions old, so it’ll probably need some work to be compatible with Maple. And it does require a tweak to one file in Open EdX, since cohorts are originally designed in Open Edx to only be editable by staff members. But have at it if you like!

4 Likes

@john_curricume I’m interested in using this. Do you have any sense of what kind of work will be required to make it work with Nutmeg? (I.e. I can just try it as-is, but then I’m not sure what I’ll need to know to debug anything that goes wrong…)

Yeah, I tried doing all the steps for Nutmeg, but at the end I just don’t have any new component show up under Advanced when I try to add it to the class (and yes I added it under Advanced Settings, changed the source code, and enabled ALLOW_ALL_ADVANCED_COMPONENTS via a tutor plugin like:

---
name: cohort_self_select
version: 0.1.0
patches:
    cms-env: |
      "ALLOW_ALL_ADVANCED_COMPONENTS": True

which I confirmed shows up in

/home/ubuntu/.local/share/tutor/env/apps/openedx/config/cms.env.yml:"ALLOW_ALL_ADVANCED_COMPONENTS": True

)

@Rohan I’ll give it a shot to bring it in line with Nutmeg. I’ll aim to get back to this thread by next Wednesday with an update.

1 Like

That is super-appreciated! Thanks!

@Rohan this has been updated now. Give it a shot and let me know how it goes!

2 Likes

I was able to get the xblock showing up now!

But I’ve got a question about the “Access the LMS/CMS docker container:” steps. Don’t these containers get rebuilt every time someone does “tutor images build openedx”? And therefore wouldn’t this checked out copy inside the container get removed in the future?

I’m already using a custom invocation of

tutor images build openedx --build-arg EDX_PLATFORM_REPOSITORY=https://github.com/username/edx-platform.git --build-arg EDX_PLATFORM_VERSION=my_branch_with_changes

In order to persist the suggested changes to edx-platform/openedx/core/djangoapps/course_groups/views.py (and I recommend changing the instructions to recommend other people do the same), but that would still leave needing to find a way to automatically install the plugin. Are you aware of any way to do this? Or am I off-base that it will not persist?


Also, once I tried to use the cohort selection from a student account, I encountered two issues:

The first is that the naming of cohorts doesn’t seem to be alphabetical, as shown below:

Is there a way or change that can be made to enforce alphabetical ordering here? I can just rename cohorts to fit the ordering (which is the same as what’s show on the Instructor → Cohorts page), but I just thought I would ask.


The second issue is more critical. When I log in as a beta tester student, I see that they were correctly assigned to Cohort3 which is what I have set for the “Automatic” enrollment (i.e. the default enrollment.) The Cohort1 and Cohort2 are set to manual enrollment (but let me know if that’s not correct.) When my student user selects Cohort1 for themselves, first of all there’s no “submit” of any sort which seems a little suspicious.


image

But the issue is that if the student then goes to the next unit, and then comes back to the previous unit, the cohort self-selection has disappeared:
image

Just incase maybe it was un-enrolling the student on going back to that page, I then went back and selected Cohort2, and then moved forward. But when I went and downloaded student data, the student was still set to the Cohort3, not Cohort2, which basically seems to suggest that the change isn’t persisting. Any thoughts on why this may be?

@john_curricume is this the expected behavior for the 2nd issue?

@Rohan I was on vacation but am back now and spoke to my dev team about it. There are more changes in Nutmeg that require additional customizations to the code for this to work. We aren’t sure what all of them are but we’ll be researching it to get this block working (we want it for ourselves too). Not sure exactly when we’ll have those turned around but should know more soon.

This is very much appreciated, thank you!

Hey Rohan,
Updates made, so the cohort selection should persist now.
There is no submit button, it just recognizes that the user made a selection and shows the confirmation message like the following:
image

Let me know if it is now working on your system.
Best,
John

@john_curricume no luck :frowning: I don’t see any green confirmation text like that when selecting from a student account still, and they can’t see the cohort-restricted content.

First I tried upgrading via

git pull origin master
cd ..
pip install -U --no-deps cohort-selector-xblock/
tutor local restart

And while it said the reinstall succeeded, that didn’t change the observed behavior. So then I went to rebuild my open edx image incase that was needed, but it seemed to say that everything was fine and still could use the cache. Then I did a “tutor local quickstart” but the result was the same as the local restart; no green text or changed behavior.

Any guidance on further debugging steps/logs I can check for?

Hey @Rohan, a couple things potentially:

  1. Did you make the modification to views.py that is mentioned in the README?
  2. Any errors in logs or console that you can share?
    Let me know!
    John

Re views.py, yep, I mentioned my custom build command that references a fork w/ the changes.

Re errors in logs, I’d need to know what to search for? (Also FYI I’m going to be out for work for a couple weeks and may be delayed in replying after today.)

@john_curricume can you confirm this is currently working for you in Nutmeg? I went through all the steps from here again, and didn’t experience any errors during the pip install or anything like that (and I have the views.py changed in my branched edx-platform), but I’m still not seeing the intended behavior. I suspect there may be an instruction that’s missing…

And here’s how I have the cohorts and content groups and restricted content set up:

And the movement between cohorts as a student seems to work…

But I’m also just now noticing a weird error when I tried to add that new “Pick Your Content” unit.

Instead of starting off as “restricted” to “All learners and staff”, it’s set to an indeterminate “Select a group type” value as shown below:

If I select Content Groups, and then select all 3 content groups, and hit save, then it shows up as being restricted to all 3 groups. But then when I go back and try to change the types, now I’m given the “All learners and staff” option, as shown below:

But then when I save that, it goes back to being in the erroneous “Select a group type” state.

So yeah, it feels like it’s close, but something feels like it’s missing (and so far, no matter which content group I have a user select, they still never see the restricted content :-/)

@Rohan glad to hear it’s gotten this far for you, and thanks for all this context around the issue. Let’s see if we can get it to the finish line. All the block does is switch a user from one cohort to another. After that, it’s job is “done”.

So to confirm that part, can you go to the Instructor tab and confirm that you can use the x-block to swap cohorts and you see it reflected in the numbers here?

It seems like the answer to that is “yes”. If so, then the short answer is the block’s job is done and once a user is in a cohort then cohorts and content groups control visibility (and the block doesn’t touch those things). I can confirm that I don’t see any issues with visibility controls in a Nutmeg instance I’ve got up. This is a user in Cohort A who can only see “Cohort A” and “all Groups” content:

Even though there are actually 4 units, but with different visibility rules:

So if your user is getting into a cohort and your cohort is attached to a content group (as you’ve shown) then the piece that seems like it isn’t working is that Content Groups just aren’t “sticking” when you apply them. Let’s break down that problem:

Of the 1 through 3 in the screenshot above, which one (if any) breaks?
Also, if you try using cohorts and content groups to restrict content in a separate course without the x-block, is the result any different?

Thanks for the further help. It appears to me that I was probably being blocked from observing the correct behavior with this component due to experiencing a completely different error while I was testing it. I reverted back to an earlier custom edx-platform repository, and re-applied the cohort-selector-xblock install instructions, and I started seeing theoretically-correct / closer-to-what I expect behavior. But I want to confirm with you if what I’m seeing is what’s expected…

As the instructor, I set the test student to the DefaultCohort (which is not associated with any content groups)

I then set the first section for content group / cohort selection to accessible to all content groups

(When I’m assigning the student to DefaultCohort by default, the first section needs to be unrestricted otherwise they can’t see it to select it.) And I don’t see any errors in the console window,

and I do see the “access to this unit is restricted” messages.

When the student logs in, they see all the sections. Is that expected? I would have thought the subsection would be hidden if all units were hidden (and I thought I had seen someone mention that before on this forum, but I can’t find it. But even if this isn’t the official behavior, is it what you see?)

If they click into any of the “Subsection for ContentGroup1/2/3” sections before they select a cohort, they see “There is no content here” (which is what I would expect.)

When the student goes to select their cohort, there is a cached entry there apparently from my prior tests, even though I manually re-assigned the student to the DefaultCohort. This is a minor thing, but again I’m just curious if this is expected.

If I select Cohort3, then I do see the correct message about movement from the cohort I had manually assigned them to (DefaultCohort) to the one they chose (Cohort3).

After that, if they hit the “next” button, they will go through the Subsections for Cohort1 and 2, which correctly continue to display “no content” (though I would prefer they didn’t show up at all. But this is perhaps back to the previous issue with the Subsections continuing to be visible even when they have no visible content.)

And finally when they hit next to get to Cohort3 content, they correctly see the Cohort3 content.

So maybe everything is working at this point? And maybe it’s only my expectations that are incorrect about
a) Subsections disappearing when no visible units are within?
b) The cohort selection pulldown not caching old selections for re-display?

@Rohan yes, this seems to be expected behavior at this point:
A) My understanding (and some quick testing) confirms that Open EdX will still show a subsection in the course outline even if that user can’t view any content in that section (because of content group rules or otherwise)
B) Yes, that seems likely that the cohort selector might cache a cohort and display it in the dropdown even if an admin changes the actual cohort in the back-end. I don’t think that block “re-checks and reloads” a cohort assignment every time it is loaded, it probably just saves the last selection in the state data. This shouldn’t affect the actual assignment and what a user can view, ultimately.
John