Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow enrolment even if there is already another enrolment in a course #21

Closed
mastnym opened this issue May 4, 2018 · 3 comments
Closed

Comments

@mastnym
Copy link

mastnym commented May 4, 2018

Hello Nicolas,
thank you for this wonderful plugin first. I just want to elaborate about one feature of your plugin.
When enroling users, for yeach user you're checking wheather this user is already enrolled in this course and if he/she is, you skip the enrolment:
if (is_enrolled(context_course::instance($enrol_attributes_record->courseid), $user)) { continue; }

Is this the right behaviour?
In my case, we have a student, who's enrolled in a course thru external database plugin. After finishing th e course, he is suspended (not unenrolled, because we want to have his/her progress in course in case we want him back). Later on, when he/she becomes a PhD. student, he/she gets an attribute of his/her department and I want to enrol him/her into the same course with a special role (PhD. student, so he/she sees the contents of a course). But I can't do that, becouse he/she gets skipped, because of the prevoiuos role.
Are there any reasons (which I obviously don't see:) ), that prevent you from doing this?
I think, it should be admns responsibility to set up your plugin right, so that users don't get multiple roles etc. What do you think? I would probbably start with skipping inactive course roles, eg: checking only active:
if (is_enrolled(context_course::instance($enrol_attributes_record->courseid), $user, '', true)) { continue; }
Where the last true argument filters only active enrolments.
Thanks for your answer, Martin

@ndunand
Copy link
Owner

ndunand commented May 7, 2018

Hello Martin,

Thanks for your feedback and for pointing this out. This might indeed not be the best way to handle things, I think it just made sense here in our local use case.

There are no other reasons for the plugin excluding people who are already enrolled.

I agree with what you suggest, but maybe the plugin could even disregard completely other enrolments. What do you think ? I'd have to check and test.

@mastnym
Copy link
Author

mastnym commented May 9, 2018

Thanks for your feedback Nicolas. I completely understand the local use case :) Anyway, since Moodle permissions are aggregated and there is an ALLOW and PROHIBIT choice (which overrides every other role setting), there should not be a theoretical problem to disregard all other enrolments and just enrol the user.
The only thing I'm now afraid of is how other users use your plugin and if you make a change in your code how it affects them.

We are using your plugin to assign roles with less priviledges than the user might already have. So that is fine and will be fine(permission aggregation) on all other instances that use your plugin. I'm 99% sure, that in our enviroment this change will not make any mess. On the other hand, if you use your plugin to give user a role with more priviledges some users might get access to areas,which they don't have before. But...this is right, everything is up to admin and his setting. This may only lead to some confusion for the user. For example, if there is a non editing teacher, which has an external attribute edit-questionbank, then IMHO he/she should get additional right/role(elevated privilidge) to be able to edit question bank no matter what. If you don't want this to happen, then you should delete the attribute from this user.

If I were you, I would disregard all other enrolments. I can't think of any bad circumstances right now. Does it make sense?

@ndunand
Copy link
Owner

ndunand commented May 14, 2018

Thanks Martin for sharing your thoughts about this. I agree with you, the plugin should simply disregard any other erolments. I'll release an update fixing this soon.

ndunand added a commit that referenced this issue May 14, 2018
@ndunand ndunand closed this as completed May 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants