Itamar Tzadok

A quick expalanation how to individualize a Dataform activity and note to myself to update the docs.

One setting and two permissions can affect whether the user can is limited to viewing only his/her entries.

Separate participants by activity setting

The activity setting 'Separate participants' set to 'Yes' will restrict all roles which do not have the 'mod/dataform:manageentries' capability to their own entries. By default permissions, that's all roles below editing teacher. This means that non-editing teachers are also restricted to their own entries by this setting. If you want to allow non-editing teachers (graders/TAs) access to certain entries you can use an Entry access rule and set the rule with entry filter to fetch the designated entries and a role override where you assign the designated non-editing teacher to the editing teacher role.

Separate participants by denying the mod/dataform:entryanyview permission

By default the mod/dataform:entryanyview permission is granted to everyone. You can exclude certain roles in the activity level by removing the role from the permission (Prevent), or by adding the role under Prohibited. Note that if you want to then grant the permission to particular users from the excluded role, use the Prevent method and then add an Entry access rule with a proper override.

hth

Well, the Dataform is well supported and there is no intention to drop support in the near future. You can see the changelog in the Set: Dataform tracker.

To put things in perspective, the Dataform is maintained and further developed on the most recent Moodle dev version. On production we are currently using Moodle 2.6 and a backported version of the Dataform. Dataform activities are created on Moodle 2.9 dev and imported by way of the Dataform preset into Moodle 2.6 courses. And it works. We will be using Moodle 2.8 and the respective Dataform 2.8 in the next academic year.

The Dataform allows for separate participants mode by activity setting or by permission. It allows for multiple entry states and defining transitions between states by role. And so on.

That said, if you want to try hacking the Database code then the culprit code is in mod/data/lib.php around line 840:

    if (has_capability('mod/data:approve', $context)) {
        $record->approved = 1;
    } else {
        $record->approved = 0;
    }

hth

Stop using the Database and start using another module in its stead for this purpose?

Afaict there is no way but hacking the code.

We have group assignments in the Dataform module, which allows for far more complex assignment structures, e.g. multiple submission types in the same entry and timed workflow. With this module we can deliver collaborative assignments such as Group Peer Review, alongside standard assignments.

Which module one uses for group assignments doesn't change the reasoning I have proposed. If you apply separate groups mode and allow content from one group to be available to a different group without the consent of all members of the originating group, you break the integrity of the assignment.

Or better, you can omit the list template footer described above and change the list tempalte header part to

<button id="printbutton" onclick="preparePrint();window.print()">PRINT</button>

One more thing. The region-main element may still be theme dependent, so you need to inspect the page to make sure you refer to the correct element. Alternately, you can wrap the content of the list view with an identified element and use that element instead of region-main. To do that you can open a div element in the list template header

<div id="myListContent">

and close it in the list template footer.

</div>

and of course change the respective line in the javascript to

    var mainregion = document.getElementById('myListContent');

Note that since the html in the header and footer parts of the template is effectively broken, you will have to turn off the editor when editing the template so that it is preserved.

hth