You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we recently noticed that the "Availability" label in assignments settings is replaced with JSON code if the assignment has restrictions.
To reproduce this issue, follow these steps:
Enable metadata for modules
Add an assigment with at least one restriction (it doesn’t matter which one)
Go back to settings for the newly created assignment
You should see that the JSON code that describes the restriction has now replaced the "Availability" label.
Why is this happening ?
Well, Moodle is kinda responsible for this…
In the "course_modules" table, there is a "availability" column which will contain JSON if the module has some restrictions. Now, when building the form for the assignment, Moodle creates a header with the same name as the "availability" column and sets the value as a simple string that will be translated for the user (Availability in English).
In this plugin, there is a Moodle hook that will add any module metadata to the form (see coursemodule_standard_elements in context/module/classes/context_handler.php).
The problem with this method is that every piece of information is fetched from the database as an stdClass object which is then merged with metadata for this particular module. Finally this object is passed to populate the form. If the module has restriction, the "availability" header of the form is being replaced by the value of the column "availability" stored in the "course_modules" table (aka JSON value).
$formwrapper->get_coursemodule() could possibly be used instead of $this->get_instance() which builds the query to fetch the module information from the DB, but we pretty much get the same object with "availability" column. I’ve tried to make a simple intance object with the module id:
$instance = new \stdClass();
$instance->id = $this->instanceid;
local_metadata_load_data($instance, $this->contextlevel);
$formwrapper->set_data($instance);
and it works.
I believe this is working because the form is probably populated with values for the default assignment fields and it only needs the values for additionnal metadata fields. This is just a guess of course.
The text was updated successfully, but these errors were encountered:
Hi,
we recently noticed that the "Availability" label in assignments settings is replaced with JSON code if the assignment has restrictions.
To reproduce this issue, follow these steps:
You should see that the JSON code that describes the restriction has now replaced the "Availability" label.
Why is this happening ?
Well, Moodle is kinda responsible for this…
In the "course_modules" table, there is a "availability" column which will contain JSON if the module has some restrictions. Now, when building the form for the assignment, Moodle creates a header with the same name as the "availability" column and sets the value as a simple string that will be translated for the user (Availability in English).
In this plugin, there is a Moodle hook that will add any module metadata to the form (see
coursemodule_standard_elements
incontext/module/classes/context_handler.php
).The problem with this method is that every piece of information is fetched from the database as an stdClass object which is then merged with metadata for this particular module. Finally this object is passed to populate the form. If the module has restriction, the "availability" header of the form is being replaced by the value of the column "availability" stored in the "course_modules" table (aka JSON value).
$formwrapper->get_coursemodule()
could possibly be used instead of$this->get_instance()
which builds the query to fetch the module information from the DB, but we pretty much get the same object with "availability" column. I’ve tried to make a simple intance object with the module id:and it works.
I believe this is working because the form is probably populated with values for the default assignment fields and it only needs the values for additionnal metadata fields. This is just a guess of course.
The text was updated successfully, but these errors were encountered: