We just upgraded one of our clients sites that makes extensive use of the meta-course enrolment feature combined with ‘nosyncroleids’ from 1.9 to 2.2 – they use meta-courses to enrol their students but use manual enrolments for their teachers so the teacher role was set in ‘nosyncroleids’ – during the upgrade these manual enrolments for teachers seem to have been corrupted – after upgrade the users show as “enrolled” using meta-enrolment but don’t have any roles in their courses. This seems strange as in the 1.9 site they were “manual” enrolments.
It looks like Petr Skoda may have fixed this as part of MDL-29684 but this is only fixed in master, not the stable branches. (and I haven’t tested it)
And unfortunately as the sync process has already screwed up the enrolments on the courses, simply applying the patch to the clients 2.2 site wouldn’t work – the only way it seems it might work would be to revert back to the 1.9 site and re-run the upgrade with the patch in place – or manually go through each course and fix the enrolments. Unfortunately we didn’t notice this early enough and the site was already being used so the client is now going through each course and manually fixing the enrolments for their teachers (time-consuming and frustrating!)
IMO this sort of issue should be back-ported but hopefully this post might help prevent others from experiencing the same pain!
Tags: Moodle
I had the same problem. I solved it by downloading moodle devel from Skodak mirror here: https://github.com/skodak/moodle/zipball/master
Just overwrite your 2.2.1 moodle/enrol/meta folder with skodak’s version and do the upgrade. On the next cronjob everything will be fixed.
Do a full file and database backup before do this.
great to hear it worked for someone – we couldn’t re-run the upgrade in this case as the site was already in production and was being used. 🙁 – I wish we’d noticed it earlier!
You can do this on your already upgraded production site. Just overwrite the meta enrolment plugin as I said. Moodle will upgrade the plugin by visiting /admin/ and the blank roles will be fixed in the next cronjob.
yeah – that didn’t seem to work for us – it removed the blank roles but didn’t replace them with the original “manual” role assignments that were there in 1.9 – the site had been adjusted a bit and potentially work done to track the issue down may have compromised the data further 🙁