Auto Group

General plugins (Local) ::: local_autogroup
Maintained by Mark Ward, Emma Richardson, Arnaud Trouvé
A local plugin which automatically assigns enrolled users on a course into groups dependant upon information within their user profile. (Now with custom profile field support - called User Info Field in settings.) This plugin will create, update, and delete groups automatically to match the users on your course. All behaviour is event-driven and so will occur within page loads. The system can also monitor manual group setting changes and moderate them to ensure that groups are kept neat and tidy.
Latest release:
657 sites
286 downloads
51 fans
Current versions available: 5

A local plugin which automatically assigns enrolled users on a course into groups

dependant upon information within their user profile.

 

This plugin will create, update, and delete groups automatically

to match the users on your course. All behaviour is event-driven

and so will occur within page loads.

 

The system can also monitor manual group setting changes and

moderate them to ensure that groups are kept neat and tidy.

Screenshots

Screenshot #0
Screenshot #1

Contributors

Mark Ward (Lead maintainer)
Emma Richardson: Maintainer
Arnaud Trouvé: Contributor
Please login to view contributors details and/or to contact them

Comments RSS

Show comments
  • Mon, Nov 9, 2020, 8:17 PM
    That really does not make much sense. This plugin creates groups based on user profile fields. If you change a profile field, the group will be created and updated at that point. It does not add users to existing groups unless the group was originally created by the plugin. So there is no need to reconfigure the plugin ever - just change what is in the profile field that the plugin is configured to watch...
  • Fri, Nov 20, 2020, 9:50 PM
    Just done a quick test on a fresh 3.10. It seems works correctly . smile
    I let Emma (current lead maintainer) to do more extensive tests and update plugin details to add 3.10 as supported versions.
  • Thu, Nov 26, 2020, 9:55 AM
    Hey, great work! This plugin really saved my bacon, removing the need to manually create groups for each department in each course and keeping users synchronized (some people change departments like other change their underwear...). Now saying "make groups for all the departments" in the courses that need it suffices. Couldn't be happier!
  • Thu, Dec 17, 2020, 11:00 AM
    Moodle 3.8+

    Not sure if I've got a bug or if it is poorly configured, but we''ve been seeing groups created manually in a course lose members - they are added manually, and the next day they are no longer in the group they were added to.

    I thought Auto Group didn't touch manual groups, only the groups it created?

    The plugin was disabled last night, but the 'leakage' of members out of the manually created groups still happened. I'm hoping this is just a simple misconfiguration, but right now I've removed the plugin as it is the only thing I added before this was taking place.

    Curious as to why it might have happened even when disabled - and of course it could be something completely unrelated to Auto Group... but it has never happened in any other Moodle we have running - only in the one with Auto Group.

    Any ideas?
  • Thu, Dec 17, 2020, 8:38 PM
    Are the groups that you are losing members from named the same as some of the autogroups created? If you are still losing people after the plugin was disabled, then I would presume that it has nothing to do with the plugin - can you check the logs?
  • Fri, Dec 18, 2020, 10:06 AM
    Thanks Emma - I checked and no, the groups losing members are not created by Autogroup. The users were added manually, but autogroup was running in the site and had a few settings looking at user profile fields. The specific course where it was active contained one group that it created, based on user email addresses. The other groups were all manually made.

    The logs show nothing, unfortunately. Does autogroup log its activity or changes it makes?

    When I disabled the plugin the effect still happened. When I removed the plugin yesterday and checked today, the groups are still intact. I understand the disabled plugin should not have affected anything, but I am wondering if there is a Cron process using those settings which is not disabled?

    To summarise, autogroup config that I was using appears to have removed users from groups that autogroup didn't create, and those users were manually added to the groups. Disabling autogroup in the site admin didn't change the effect, but removing the plugin seems to have stabilised the groups today. I am reasonably sure it may have been a config issue, but there is a possibility of a Cron job actively updating group members. Either way, the only way I could see to prevent it was to remove the plugin.

    Apologies for posting this on the plugin page - is there a discussion area where this should go?
  • Fri, Dec 18, 2020, 8:41 PM
    Maybe create an issue in github and we can discuss there - I have my site on 3.8.3 - going to check on that...
  • Wed, Jan 27, 2021, 11:49 PM
    Have been using the plugin for a while on Moodle 3.9 and it works well organizing our students into groups.

    However, all of our teachers teach more than one group and I can´t see a way to have them belong to multiple groups based on the content of a single profile field. Even if I manually add the teachers to several groups after reload they are later removed from those groups by the plugin. Is there any way around this?
  • Wed, Jan 27, 2021, 11:53 PM
    I do not use the plugins to assign my teachers. I just do that manually. Just uncheck the teacher role from the plugin.
  • Wed, Apr 21, 2021, 5:47 PM
    Firstly, thanks for this plugin which is really useful and excellent - but I am noticing a slight annoying issue, in that it doesn't appear to always trigger. I have paypal set up as an enrolment method on courses, and for some reason sometimes the autogroups will trigger, but sometimes it doesn't when a user is enrolled via Paypal (the other enrolment methods seem to be working OK all of the time). I have the settings for the plugin set so all 4 triggers at the bottom of the admin page are ticked. We are getting scenarios, where a user is enrolled on the course as a student, the autogroup is set up to action students - but it doesn't. If I go into that users profile and save changes but without changing anything, the autogroup is then triggered at that point.

    Has anyone else seen a similar behaviour - and if yes, is there a solution.
  • Fri, May 14, 2021, 3:34 AM
    It is very possible that it is not being activated by the paypal enrollment method. If you have a fix for it, please feel free to submit a pull request on github.
  • Fri, May 14, 2021, 2:14 PM
    Thanks Emma for replying to my question. My host company has identified the problem. Even though I have set a custom profile field to default to a certain value, it apparently doesn't actually write that value into the relevant table containing the user data, which means that the autogroup plugin doesn't pick it up. If I ook at the users profile it does display that default value, even though it hasn't been applied to them yet. If I edit the users profile and save without actually changing anything, that then does write the value into the table, and the autogroup kicks in as it should. This appears to be a core moodle bug not a bug with the plugin, and has been reported accordingly, but I guess there may be merit in adding that warning to plugin page, so others aren't caught out the same way?

    The other information that I deduced was that it isn't to do with the Paypal plugin, it is for accounts that are created by self-enrolment on the site.
  • Fri, May 14, 2021, 7:28 PM
    Interesting - I can see why that is happening. That you maybe do not want self registration accounts writing to the database until they are confirmed so that the database is not filled up with spam etc...i.e. it might not be a bug but intentional behavior...
  • Fri, May 14, 2021, 7:56 PM
    @Emma - the data not being added to the table, still continues even after the person has confirmed. I could understand it not writing to table straight away as you say, but on confirmation I think it ought to write to the table at that point.
  • Fri, May 14, 2021, 7:59 PM
    Oh, ok, then - that does sound like a bug. I wonder if you could work around it by not providing a default value but making them enter something in there (not sure what kind of data but maybe you could do a dropdown so that the data was consistent). Maybe if something is actually selected, it would save correctly.
1 2 3 4 5
Please login to post comments