Back in 2011 I posted this illustration in Displaying entries categorised:
You simply add a certain pattern of the Dataform select (menu) field and it displays the value only once. And you can have sub-categories with further select fields.
Per chance, I'm revisiting this feature for the new version of the Dataoform.
May not be useful for you as this is, or rather was, a feature of the Dataform select (menu) field. But for what it's worth ...
$context = context_course::instance($courseid);
$roleid = $DB->get_field('role', 'id', array('shortname' => 'teacher'));
$roleusers = get_role_users($roleid, $context);
foreach($roleusers as $user) {
$email = $user->email;
// Etc.
}
Better use the API than construct all kinds of direct queries that may work today and break tomorrow.
hth
A nice give and take, formative assessment, leisurely journey towards final assessments is actually more difficult in Moodle.
What functionality is needed for having that really nice and easy at the course level?
David, please do not assume that Moodle test developers will not be able to understand that
Then "element" "selector" should exist
and
Then "element" "selector" exists
are two phrases for the same step.
Gherkin is supposed to look like natural language (a subset of) and as such it already has some ambiguity. Given, When, Then, And, But are interchangeable, but only most of time.
I'm inclined to think that only people who've taken one too many philosophy courses (I for one ) would be bothered by the difference between the potentiality in the first and actuality in the second, or even notice it. Others would probably just use one or the other.
Note that I'm not suggesting to deprecate and replace the "should" terminology. Merely to extend the vocabulary. And most importantly, the extension does not require touching the php. Just adding a few more @Given declarations as aliases.
In many cases acceptance tests are acceptance criteria for delivery. As acceptance criteria they need to be factual rather than potential. The client can set a criterion such as "When I go to A then I see X but I don't see Y". The testing language can match that. Just terminology, I know, but sometimes terminology may be useful.
Language speakers already cope with arguably quite confusing language. So I'm not worried that enriching the testing language with additional phrases for same steps would be a problem. This can be easily done by by aliases. I have not found any documentation on that but it turns out that you can declare more than one @Given in a step definition (without adding or duplicating code) and all these givens will be recognized as valid steps.