Error when users are enrolled in too many courses (or long course names) about moodle-block_course_overview_campus

[abias]

Hi,

this issue has been stale for 1.5 years now.

While we still would like to see this issue fixed, it won't be done anymore as we are foreseeably transitioning our own usage of this block to the Dashboard blocks which have been dramatically improved from Moodle 3.6 on and thus can't spend any more substantial resources on this plugin.

Fixing this problem would require to change the logic of storing hidden courses not in (length-limited) user preferences but in a custom table, including the creation of custom webservices for getting and setting the values.

Since this issue was reported, only one of our own users has hit the limit and turned his Dashboard unusable.
We decided to go with this hack for the time being:

[root@moodle1 moodle_prod]# git diff lib/moodlelib.php
diff --git a/lib/moodlelib.php b/lib/moodlelib.php
index 79c93fe..8ab9a9f 100644
--- a/lib/moodlelib.php
+++ b/lib/moodlelib.php
@@ -1893,7 +1893,13 @@ function set_user_preference($name, $value, $user = null) {
     }
     // Value column maximum length is 1333 characters.
     $value = (string)$value;
+/* KIZ MODIFICATION START
+   REASON: Invalid value in set_user_preference() call, value is is too long for the value column */
+    if (core_text::strlen($value) > 3000) {
+/* KIZ MODIFICATION END */
+/* ORIGINAL START
     if (core_text::strlen($value) > 1333) {
+   ORIGINAL END */
         throw new coding_exception('Invalid value in set_user_preference() call, value is is too long for the value column');
     }

This hack has to be accompanied by a SQL change of the user preferences table which, in Postgres, looks like this:
ALTER TABLE mdl_user_preferences ALTER COLUMN value TYPE varchar(3000);

As soon as we retire this block, we can change the table back with
ALTER TABLE mdl_user_preferences ALTER COLUMN value TYPE varchar(1333);

I am really sorry for the hassle which this bug has caused, but I rely on your understanding of our limited resources.

I will keep this issue open as a reference for anyone who also stumbles into the problem.

Cheers,
Alex

[abias]

Hi Klaus,

first of all, I am sorry to hear that you encountered this problem. This shouldn't have happened.

Then, this problem only occurs if you are using our plugin local_boostcoc at the same time. Can you please confirm that you also use this plugin?

The underlying problem is that we decided to store the list of not-shown courses for local_boostcoc in a user preference. Unfortunately, user preferences are quite limited in length (see https://github.com/moodle/moodle/blob/master/lib/moodlelib.php#L1898) which we were not aware of until now.

If we calculate with 5-digit course IDs, this limit will be broken at approx. 160 enrolled courses. That's why we haven't hit this limit in our instance yet.

If you read through https://tracker.moodle.org/browse/MDL-46739, you will see that there were plans to change user preferences to a (longer) text field in DB, but there were objections / discussions about side-effects and the thing was neither finished nor closed as won't fix.

As a long-term solution, I will rebuild the storage of this data in a separate table. But this will take some time and won't be finished before the end of october, I'm afraid.

As an intermediate-solution, I can only recommend you to replace the existing line https://github.com/moodleuulm/moodle-block_course_overview_campus/blob/master/locallib.php#L436
which currently reads

// Store the current status of not shown courses.
set_user_preference('local_boostcoc-notshowncourses', $jsonstring);

with

if (core_text::strlen($jsonstring) < 1333) {
    // Store the current status of not shown courses.
    set_user_preference('local_boostcoc-notshowncourses', $jsonstring);
}

For the users who had the debug message which you quoted before, filtering the courses in Boosts nav drawer will be broken then until there is a real fix, but all other user will still have the same functionality.

I will keep you updated.

Thanks,
Alex

[zidludwig]

hi Alex,
thanks for the workaround! Only i took
if (core_text::strlen($jsonstring) < 1333) {

best
Ludwig

[abias]

thanks for the workaround! Only i took
if (core_text::strlen($jsonstring) < 1333) {

Damn, you're right, of course. That was a copy & paste mistake. I fixed it in my comment above.

[superklausi]

thanks Alex for your help. the workaround does work as you described.
We would appreciate a "real" fix as soon as you find time to do it.
Again, thanks for your great work!