emmarichardson / local_autogroup Goto Github PK

Hi, i'm not sure if we need to try to populate a different or custom profile field but if using defaults, we'd aim to populate multiple values to a text field. Use case is course and major codes which could often be multiple values eg "B1330,B1335".

i'd really like to be able to use auto group to group based on these values, so i'd end up with B1330 group and B1335 group.

I'm not sure if this would require an enhancement to auto group or if we need to get something custom built.

Thanks for any help you can offer - cheers

Can't find course settings (second screenshot on moodle plugin's page).
Only way to add auto groups to course is direct link:
https://"yoursite"/local/autogroup/manage.php?courseid=“yourcourseid"

Hi

Would it be possible to add an automatic grouping creation feature?

This grouping would take the name of the profile field and would group all the groups created from this field in course.

Admin system level

Course level

Thanks

Hello,

Sorry for the next issue adding. I just think it will be good to inform you.
When there is more than one Auto Group set (for example, two profile fields), error is shown with debuging on
"Exception encountered in event observer '\local_autogroup\event_handler::user_updated': This ID number is already in use".

Backtrace:
line 125 of /local/autogroup/classes/domain/group.php: call to groups_create_group()
line 405 of /local/autogroup/classes/domain/autogroup_set.php: call to local_autogroup\domain\group->create()
line 301 of /local/autogroup/classes/domain/autogroup_set.php: call to local_autogroup\domain\autogroup_set->get_or_create_group_by_idnumber()
line 100 of /local/autogroup/classes/domain/course.php: call to local_autogroup\domain\autogroup_set->verify_user_group_membership()
line 80 of /local/autogroup/classes/domain/user.php: call to local_autogroup\domain\course->verify_user_group_membership()
line 64 of /local/autogroup/classes/usecase/verify_user_group_membership.php: call to local_autogroup\domain\user->verify_user_group_membership()
line 154 of /local/autogroup/classes/event_handler.php: call to local_autogroup\usecase\verify_user_group_membership->__invoke()
line ? of unknownfile: call to local_autogroup\event_handler::user_updated()
line 155 of /lib/classes/event/manager.php: call to call_user_func()
line 75 of /lib/classes/event/manager.php: call to core\event\manager::process_buffers()
line 834 of /lib/classes/event/base.php: call to core\event\manager::dispatch()
line 282 of /user/editadvanced.php: call to core\event\base->trigger()

Steps to reproduce:

1. Navigate to course and open auto groups (Course -> users -> groups -> auto groups)
2. Click create new group set and pick any profile field
3. Select only student as a role and save changes
4. Repeat steps 2-3 just to add another auto-group with different profile field
5. Navigate to users enrolled to that course and change their profile fields from step 2 or 4

Group will be created well with user enrolled, error shown does not interrupt plugin.

Best regards,
Olena Tatarintseva

Getting the following error in 4.3...Fields list in snapshot record does not match fields list in 'groups'. Record is missing fields: visibility, participation.
4.3 has added two new fields to the groups table. I have tried adding the missing fields to both domain/group and autogroup_set but error persists. It does not seem to affect the functionality.
@ak4t0sh do you have time to see if you can come up with a fix?

Informações de depuração: ERROR: syntax error at or near "JOIN"
LINE 1: DELETE FROM mdl_local_autogroup_manual LAM JOIN mdl_groups G...
^
DELETE FROM mdl_local_autogroup_manual LAM JOIN mdl_groups G ON (G.id = LAM.groupid) WHERE G.idnumber NOT LIKE $1 ESCAPE ''
-- line 97 of /local/autogroup/db/upgrade.php: call to pgsql_native_moodle_database->execute()
[array (
0 => 'autogroup|%',
)]
Error code: dmlwriteexception
Rastreamento de pilha:

line 489 of /lib/dml/moodle_database.php: dml_write_exception thrown
line 293 of /lib/dml/moodle_read_slave_trait.php: call to moodle_database->query_end()
line 338 of /lib/dml/pgsql_native_moodle_database.php: call to pgsql_native_moodle_database->read_slave_query_end()
line 836 of /lib/dml/pgsql_native_moodle_database.php: call to pgsql_native_moodle_database->query_end()
line 97 of /local/autogroup/db/upgrade.php: call to pgsql_native_moodle_database->execute()
line 703 of /lib/upgradelib.php: call to xmldb_local_autogroup_upgrade()
line 1929 of /lib/upgradelib.php: call to upgrade_plugins()
line 713 of /admin/index.php: call to upgrade_noncore()

Hello,

It looks like most of *.php files don't use
defined('MOODLE_INTERNAL') || die();

e.g locallib.php

I am not sure is there any reason to skip this check?

Thanks a lot for your job with this plugin.

Best regards,
Olena Tatarintseva

I am using bitnami 3.11 moodle image. When adding or deleting a user I get this error:

Notice: Undefined property: stdClass::$hidepicture in /bitnami/moodle/local/autogroup/classes/domain/group.php on line 208

Possible an error with 3.11 version of moodle?

When an auto group is edited, the Group by field always defaults to the custom profile field that was created first. The expected behavior is that the Group by setting would default to the profile field that is being used by that group. IF the user is not paying much attention, they could actually change the profile field without realizing. Let me know if you need any additional clarification.

Geoff Brewster
[email protected]

Hi! i'm new to Moodle and found your plugin, which is very accurate for a common problem.
Anyway, i'm having the following issue:

installed the plugin succesfully, activated and configured it easyly. It also created the groups for a custom field in the users profile, but when a new user signed in and completed that custom field, the group is not refreshing the data, i mean the new users whom should be in a previously created group (by autogroup) are not getting assigned to the group they should be.

Mi custom field is a combo box for "work city" of the user.

My Moodle version is: Moodle 3.9.2+ (Build: 20201002) | Versión 2020061502.04 | stable |
My autogroup plugin version is: 2.5 | local_autogroup | 2020072700

is there any check or fix to get this propperly working??

Thanks in advance, and sorry about my english (not native speaker here).
Regards!

As suggested by Vladimir Miranovic in https://moodle.org/plugins/local_autogroup « user info field » introcuced in v2.3 should be renamed to « custom profile field » which is more understandable by users.

Sort module name are displayed by their classname. I think that the class should not be renamed to avoid confusion in code but a proper display using standard moodle string manager should be implemented. This way we could separate code and display and it would allow customization and translation using AMOS.

I’ll try to work on it when I’ll have free time.

We've seen a strange incidence where a user would not update normally when we made changes to their profile, until it randomly worked, seemingly when making changes to another user. We're a little lost as to where to look as a cause of this.

We have autogroups assigning users to groups based on a customfield - into a large number of groups

(this is a large number of courses, and large number of users with lots of variation in the custom field, potentially 100+ groups per course. All in, it's tens of thousands of groups. We're aware this probably makes us an outlier in the usage of the plugin)

We have assigned a large number of users to a number of groups.

We're aware there has been an issue where the server hit php_max_children and we think that the group process may not have completed in every case in the past. I don't have the logs to prove this, but it might be key to what happened.

With generic information, what happened was this:

We observed that a new user (user1) was not included in all of their of the groups we would expect them to be in (custom_field: test1) - going by course ID, the user had been enrolled in some, but not all, lets say course ID 1-80, but not 80-100 - (this fits with our theory of php_max_children being reached causing the process to fail.)

we needed to get autogroups to enrol the user, as there are a large number of groups to set it's not feasibly really to do it by hand.

We tried checking the listen to groups options to see if this would trigger the user to be added to their group. No results.

We tried changing the value for custom_field to a placeholder. We observed autogroups making calls in the DB. The placeholder group WAS added to all their groups in all their courses, we thought we had a solution

We set the custom_field back to test1 - strangely enough, this didn't update on the courses where it failed to update previously. We were now confused.

After allowing a fair amount of time, we tried updating the values of a random user2 to do some testing, which worked as expected. At this point, about a day later, we spotted that User1 had now had their groups updated. It looks like changing user2 caused user1 to update, but we're absolutely baffled as to why.

We're hoping you can shed some insight on this. Can you advise if there are measures in place to check groups in the event of a failed update? Could the failed update have left some data in place that would cause it to not be updated again? Why would updating another user cause this to update when it didn't happen when we amended the user directly?

I came across this error on one of our courses: https://www.screencast.com/t/4Tn1Yw3J5

The strange thing is that the course doesn't have any groups. When I click the "Continue" button, it kicks me out of the course.

Running Autogroup 2.4 (2018070300) on Moodle 3.5.3

Thanks.

i'm not sure within the scope of this plugin, but i have another profile field to ID international students, just a checkbox so value 1 or 0, so when configuring auto group i was thinking it might be good to be able to have logic to name the group and populate based on the value. so if any have value 1 then create group called "international student" and populate.

I'm seeing the following error when running on Totara 11 with debugging enabled:

String [manager,totara_hierarchy] is deprecated. Either you should no longer be using that string, or the string has been incorrectly deprecated, in which case you should report this as a bug. Please refer to https://docs.moodle.org/dev/String_deprecation

    line 397 of /lib/classes/string_manager_standard.php: call to debugging()
    line 7384 of /lib/moodlelib.php: call to core_string_manager_standard->get_string()
    line 118 of /local/autogroup/classes/sort_module/primary_position.php: call to get_string()
    line 94 of /local/autogroup/settings.php: call to local_autogroup\sort_module\primary_position->get_config_options()
    line 67 of /lib/classes/plugininfo/local.php: call to include()
    line 605 of /admin/settings/plugins.php: call to core\plugininfo\local->load_settings()
    line 7966 of /lib/adminlib.php: call to require()
    line 493 of /admin/index.php: call to admin_get_root()

Moodle 3.11.12+ & Moodle 4.1.2
Postgres 12
PHP 7.4

Informações de depuração: ERROR: syntax error at or near "LAM"
LINE 1: DELETE LAM FROM mdl_local_autogroup_manual LAM JOIN mdl_grou...
^
DELETE LAM FROM mdl_local_autogroup_manual LAM JOIN mdl_groups G ON (G.id = LAM.groupid) WHERE G.idnumber NOT LIKE $1 ESCAPE ''
-- line 97 of /local/autogroup/db/upgrade.php: call to pgsql_native_moodle_database->execute()
[array (
0 => 'autogroup|%',
)]
Error code: dmlwriteexception Rastreamento de pilha:

line 489 of /lib/dml/moodle_database.php: dml_write_exception thrown
line 293 of /lib/dml/moodle_read_slave_trait.php: call to moodle_database->query_end()
line 338 of /lib/dml/pgsql_native_moodle_database.php: call to pgsql_native_moodle_database->read_slave_query_end()
line 836 of /lib/dml/pgsql_native_moodle_database.php: call to pgsql_native_moodle_database->query_end()
line 97 of /local/autogroup/db/upgrade.php: call to pgsql_native_moodle_database->execute()
line 703 of /lib/upgradelib.php: call to xmldb_local_autogroup_upgrade()
line 1929 of /lib/upgradelib.php: call to upgrade_plugins()
line 713 of /admin/index.php: call to upgrade_noncore()

The error reported by Fernando in #13 re upgrading is not just him. I also cannot upgrade to latest version with same error.

Hi @emmarichardson

In the plugin settings, I have specified a default field "Groupe d'apprentissage".

In one course, I have implemented the rule based on this field, no worries.

When I edit the rule, the menu goes to the first field in the list which is not that I specified before.

I've done some test (reorder from User Profile Fields, rename for alphabetic order) but nothing new.

After link observation, this field selected in this menu corresponds to the first field that was created, but does not correspond to the field used for the rule in the context of the course.

Could we keep the field used for the rule by default, so that I don't have to reselect it every time I edit the rule?

Thanks.

Hello, I need you help with a serious bug I have. I have created 5 different custom profile fields to allow teachers with non editing permissions create up to five different groups in a course using the auto group plugin.

This course has 400 users enrolled so far.

After teachers reached out because they were having issues with their groups, I checked on the groups of this course and I noticed that there are duplicated groups and empty groups.I had already #set the plugin to clean old groups when all the participants leave the group. I have tried to delete the empty groups manually and the site is crashing every time.

Do you know what is the issue causing this failure? Do you have any suggestion on how to fix this..?. I tried to delete the groups set types and recreate them for this course but the problem continues..

Added in Moodle 3.6 "Group messaging" feature allow to create group conversations if the option is enabled in the group settings.

As reported by Teo Pyl in https://moodle.org/plugins/local_autogroup currently local_autogroup does not allow to configure this setting. I agree that implementing it would be a great enhancement.

Hello,

Thank you for the plugin :)

I'm encountering a refresh error when I modify a user profile field in my authentication manager (Keycloak) linked to my profile via OAuth. For instance, if I change the "Service" field from "IT" to "Accounting," the change is correctly reflected in the Moodle user profile after the user logs out and back in. However, the auto-group is not updated. I need to log out and log back in again for the group to be changed.

Is it possible to execute the user profile modification search function via a CRON task to update the groups?

Bonjour,

Je vous remercie pour le plugin :)

Lorsque je modifie un champ du profil utilisateur dans mon gestionnaire d'authentification (Keycloak) lié à mon profil via oAuth, je rencontre un problème de rafraîchissement. Par exemple, si je change le champ "Service" de "Informatique" à "Comptable", la modification est bien prise en compte dans le profil de l'utilisateur de Moodle après sa déconnexion et sa reconnexion, mais le groupe automatique n'est pas mis à jour. Je suis contraint de me déconnecter et de me reconnecter à nouveau pour que le groupe soit modifié.

Est-il possible, via une tâche CRON, d'exécuter la fonction de recherche des modifications sur le profil utilisateur afin de mettre à jour les groupes ?

Hello,
​
It looks like the plugin local_autogroup is not compliant with GDPR. The plugin does not implement the Privacy API. Would you please implement it?
​
​Best regards,
Olena Tatarintseva

Getting this error in Totara 12.10 when attempting to assign a manager to a user.

Exception - Class 'position_assignment' not found
Debug info:
Error code: generalexceptionmessage
Stack trace:

• line 87 of /local/autogroup/classes/sort_module/primary_position.php: Error thrown
• line 294 of /local/autogroup/classes/domain/autogroup_set.php: call to local_autogroup\sort_module\primary_position->eligible_groups_for_user()
• line 100 of /local/autogroup/classes/domain/course.php: call to local_autogroup\domain\autogroup_set->verify_user_group_membership()
• line 80 of /local/autogroup/classes/domain/user.php: call to local_autogroup\domain\course->verify_user_group_membership()
• line 64 of /local/autogroup/classes/usecase/verify_user_group_membership.php: call to local_autogroup\domain\user->verify_user_group_membership()
• line 231 of /local/autogroup/classes/event_handler.php: call to local_autogroup\usecase\verify_user_group_membership->__invoke()
• line ? of unknownfile: call to local_autogroup\event_handler::role_change()
• line 157 of /lib/classes/event/manager.php: call to call_user_func()
• line 77 of /lib/classes/event/manager.php: call to core\event\manager::process_buffers()
• line 834 of /lib/classes/event/base.php: call to core\event\manager::dispatch()
• line 1506 of /lib/accesslib.php: call to core\event\base->trigger()
• line 843 of /totara/job/classes/job_assignment.php: call to role_assign()
• line 784 of /totara/job/classes/job_assignment.php: call to totara_job\job_assignment->update_manager_role_assignments()
• line 737 of /totara/job/classes/job_assignment.php: call to totara_job\job_assignment->updated_manager()
• line 661 of /totara/job/classes/job_assignment.php: call to totara_job\job_assignment->update_internal()
• line 313 of /totara/job/jobassignment.php: call to totara_job\job_assignment->update()

Examination of primary_position.php shows that the plugin is still trying to instantiate class \primary_position, though Totara upgrade notes show that class deprecated since version 12.0. From totara/hierarchy/upgrade.txt:

• Removed deprecated class position_assignment

I think the new class is just called \position.

We are trying to use custom profile fields for creating new groups with local_autogroup, but it's not possible.

We can define a custom profile field as the default field for autogroups (local_autogroup | filter), but when we try to configure the plugin on a course those custom profile fields aren't on the "Group by" menu list.

We are using the latest version of the plugin on Moodle 3.11

Hi Emma - thanks for looking at this.

To recap, Moodle 3.8+, using Autogroup in a course where we manually created groups and manually moved users into those groups. Autogroup created one group and one user was in it.

Overnight (possibly because of Cron) users were removed from the manual groups, and depsite disabling Autogroup this continued.

I have since removed autogroup, and there are no 'leaks' to those groups today. However, I am not discounting some kind of corruption or conflict within Moodle itself.

This could be a simple misconfiguration on my part, but autogroup is a simple tool and difficult to get wrong, as such! I am not sure what is causing the issue, and the log shows nothing. Normally, a manual add or remove to a group is logged, but I don't think autogroup adds anything to the logs..?

I should add that we run a large number of systems, but only this uses autogroup and only this has the effect.

Hoping you can help!

Hi, it seems that get_string('manager', 'totara_hierarchy') is invalid as there no such a string in totara_hierarchy lang file.
Problem found in Totara 12 and newest local_autogroup, however probably it is not a new problem.

The trace is as follows:

Invalid get_string() identifier: 'manager' or component 'totara_hierarchy'. Perhaps you are missing $string['manager']

line 356 of /lib/classes/string_manager_standard.php: call to debugging()
line 7496 of /lib/moodlelib.php: call to core_string_manager_standard->get_string()
line 118 of /local/autogroup/classes/sort_module/primary_position.php: call to get_string()
line 102 of /local/autogroup/settings.php: call to local_autogroup\sort_module\primary_position->get_config_options()
line 67 of /lib/classes/plugininfo/local.php: call to include()
line 605 of /admin/settings/plugins.php: call to core\plugininfo\local->load_settings()
line 8073 of /lib/adminlib.php: call to require()
line 7911 of /lib/adminlib.php: call to admin_get_root()
line 11 of /admin/blocks.php: call to admin_externalpage_setup()

Kind regards,
Łukasz

Hi,

I'm not sure if this is a bug or a choice.

If "preservemanual" setting is set (by default) Autoenrol keeps track of every group membership even in courses where Autogroup has not a set enabled.
In large sites, where Autogroup is used in small amount of courses, this behavior insert a lot of useless records in the local_autogroup_manual table.

Since this plugin should not work on other groups, my understanding was that "preservemanual" setting should keep track only of users manually added to groups created and managed by autogroup.

I'm missing something?

Thanks,
Giorgio

Our site is experiencing a problem with forum groups and I suspect it's related to the autogroup plugin.

In some courses (not all), groups are not applied to forums even though the course has forced-groups enabled. I tried to fix the problem by removing all groups from the course and allowing autogroup to rebuild them, but it looks like this process does not reset the forum groupid in the database, as shown here: https://www.screencast.com/t/KImDQKdh

This info might help diagnose to issue:

1. The autogroup plugin is using the Institution field to generate groups. Last week, we changed the name of the institution for about 40 user profiles. I suspect this may have something to do with the problem, but I could be wrong.

2. We changed "Institution" to "Campus" in the Moodle language string, but I doubt this has any impact on the way autogroup manages groups.

3. All the event triggers are enabled, as shown here: https://www.screencast.com/t/IBtucat7HsD9

Thanks!

H

We have autogroups set up to group by user-defined profile fields and it's worked well up until today.

we did a course copy, removed all groups and tried to reinstate the groups and we're now getting the error "This ID number is already in use". We're on version 2.8.2 and moodle 4.1. Any assistance would be appreciated.

Hi @emmarichardson

We have a bug with group changes from custom fields for accounts with OneLogin authentication.

When you manually change the group from the user's profile, you have to save it twice so that in the course the group is updated.

For accounts with authentication set to "manual", the change is immediate.

Is this a communication problem between AutoGroup and the profile of users with specific authentication or a problem with OneLogin as well?

A little video to illustrate my problem

https://youtu.be/WJ2h4XRpKTc

Hope it's understanding...

Moodle 3.11.3+ (Build: 20211008)
local_autogroup | 2.5 | 2020072700
auth_onelogin_saml | 2021010101

As I don't know if this is an AutoGroup or OneLogin problem, I will also post this message to them

Cheers.

Hi

I hope that everything will be understandable, if not, do not hesitate.

We use :

• Moodle 3.9.3 (Build: 20201109)
• OneLogin SAML SSO Authentication (auth_onelogin_saml) 2019110601
• Auto Group (local_autogroup) 2.5 (2020072700)

When we change the group name from the user profile in OneLogin (img1), the group name is changed in the Moodle user profile (img2)
But there is no change in groups in course with the auto-group plugin (img3).

It is as if onelogin does not pass the information to auto-group

A manual change from the Moodle profile works fine, and auto-group does the group change correctly.

Do you have any idea what event is missing from OneLogin or auto-group?

Thanks

This plugin needs refactoring to have Code Checker compliance.

Whenever this plugin is used in an huge site (in my case more than 10.000 users, and around 1000 courses) this plugin gets out of memory.
This has has to do with the public function __construct in which the " $this->enrolledusers = \get_enrolled_users($this->context);" get called. This is not used in the used event handler.

When replaced to the function "verify_all_group_membership" plugin works fine again...
starting from Rule 92:

public function verify_all_group_membership(\moodle_database $db)
    {
        $result = true;

        $enrolledusers = \get_enrolled_users($this->context , '' , 0 , 'u.id');
        foreach ($enrolledusers as $user){
            $result &= $this->verify_user_group_membership($user, $db);
        }

        return $result;
    }

the public function __construct will then be as follows:

    public function __construct ($course, \moodle_database $db)
    {
        //get the id for this course
        $this->parse_course_id($course);

        $this->context = \context_course::instance($this->id);

        //load autogroup groups for this course
        $this->get_autogroups($db);
    }