Unlocking needs to use events rather that assignfeedback plugin. #8
Comments
|
I have created branch with unlocking using events: https://github.com/lucisgit/moodle-assignsubmission_mahara/tree/moodle27-eventunlocking The suggested solution is fixing outstanding bugs in assingfeedback_mahara plugin:
While testing the feature, please make sure that assignfeedback_mahara is uninstalled. We need to decide if we will merge it or maintain as separate. |
|
Hi Ruslan! In general, I'm in favor of merging it all into one branch. We don't want to get into another "fork" situation. I haven't actually tried out your new branch yet, though, so I guess I should take a look at that first. :) Does this event-based branch make the feedback plugin redundant? I mean, does it achieve the same functionality as the feedback plugin (i.e. allowing the teacher to choose whether they want the Mahara Page/Collection to be automatically unlocked once it has been graded)? Because if it does, then I'm also fine with deprecating the feedback plugin. We can just tell users to uninstall it, the same as we did with the "local" plugin. Cheers, |
|
Hi Aaron, I do not think assignfeedback was "asking" teacher whether they want to unlock, the fact of having this plugin installed just handled unlocking on grading, that is it. When assignsubmission plugin setting was set not to lock at all, it did not do anything obiously. The event based unlocking has absolutely same functionality (well, slightly extended functionality, see README.md diffs for details), so it makes assignfeedback plugin technically redundant. But outcome data passing is now missing (there are no events in Moodle core to handle that). As we discussed in IRC (do not have a copy here to paste), I identified that the outcomes had a pretty custom design, as nothing in the core was using it (none of artefact plugins) and it seems has been used as a hacky way of passing outcomes data to artefacts irrespective to grading (e.g. code allowed to pass outcomes for Pages that are already unlocked). I like the idea to have it integrated, just was thinking about possible implications, may be I should add an upgrade function that would check feedback plugin presence and would fail upgrade unless feedback plugin is removed? |
|
Hi Ruslan, In practice, with the feedback plugin, you can enable/disable the unlocking behavior by choosing whether or not to use the feedback plugin on a particular assignment. That's what I meant by "asking" the teacher. If the events-based branch does the same thing (which it sounds like it does), then that's great. :) I definitely recall the discussion about removing the outcomes functionality, and I agree, let's remove it. Apparently Richard Mansfield did implement the outcomes artefact (it's here: https://gitorious.org/mahara-contrib/plugin-artefact-outcome ) but it hasn't been updated since 2010, and I doubt it even works in modern Mahara versions. I agree with your idea of adding a function to check for the presence of the feedback plugin, and tell them to uninstall it. Cheers, |
|
It would be great to utilize the events feature in Moodle! I have always thought the feedback plugin felt a bit out of place… the functionality it provides isn’t exactly “feedback” by the standard moodle definition, which leads to some confusing situations with faculty members. -Tony From: Aaron Wells [mailto:notifications@github.com] Hi Ruslan, In practice, with the feedback plugin, you can enable/disable the unlocking behavior by choosing whether or not to use the feedback plugin on a particular assignment. That's what I meant by "asking" the teacher. If the events-based branch does the same thing (which it sounds like it does), then that's great. :) I definitely recall the discussion about removing the outcomes functionality, and I agree, let's remove it. Apparently Richard Mansfield did implement the outcomes artefact (it's here: https://gitorious.org/mahara-contrib/plugin-artefact-outcome ) but it hasn't been updated since 2010, and I doubt it even works in modern Mahara versions. I agree with your idea of adding a function to check for the presence of the feedback plugin, and tell them to uninstall it. Cheers, — |
|
Ah, enabling/disabling by choosing whether to use feedback plugin will not work now, there are no extra assignment instance interface items added. Basically, if global plugin settings enables locking, then it will be locked on submission and unlocked on grading or workflow state, but no way to control it on per-assignment basis. Do you think we need per-assignment config? @upats Nice to see you joined the conversation, Tony ;) |
|
Hm, well if we want to retain the current functionality, we'll need:
On the other hand, maybe schools might actually prefer to just have it as a sitewide setting, so that their teachers don't need to worry about it? What do you think, Tony? |
|
Regarding point 1, there is a risk of situation when pages will remain locked forever in Mahara. Which seems was achievable in the situation of using feedback plugin but not selecting it on per-instance basis (or not using feedback plugin at all, but having global locking enabled). Not sure if anyone using this functionality these days, but I have a feeling that someone may use it, as this was how initial 2.3 plugin we developed (Lancaster one) worked. In general both points specified by @agwells are easy to implement, so it is not a problem to add them (unless we want to change behaviour so that there are no page remains locked after grading). |
|
You can essentially enable a sitewide setting with the feedback plugin by setting the option to have “mahara portfolio” feedback enabled by default in all assignments. We have faculty members who use both scenarios. Some programs at our university don’t care if the mahara portfolios are locked on submission and actually it would be detrimental for them if they were locked. Then there are other use cases when faculty members are grading an actual time-sensitive assignment in which case the portfolio SHOULD be locked. I think retaining the current functionality will be important for a fully-featured plugin. As for Ruslan’s observation: this is a problem we’ve thought about as well when developing our version of the plugin. We didn’t have time or resources to come up with a better solution. What if there was an option in Mahara for users to unlock their locked-portfolio, but doing so would remove their submission from the moodle assignment? Is that something that could happen? Can events be triggered in Moodle by doing something in Mahara? -Tony From: Aaron Wells [mailto:notifications@github.com] Hm, well if we want to retain the current functionality, we'll need:
On the other hand, maybe schools might actually prefer to just have it as a sitewide setting, so that their teachers don't need to worry about it? What do you think, Tony? — |
|
OK, then for this stage I will implement per-assignment unlocking setting to make functionality identical to assignfeedback. Regarding unlocking page by student - well, if submission has not been graded, it should be possible by selecting "no Page" (which will unlock previously submitted Page). If work has been graded, I am not sure it would be a good idea to allow student to revoke submission (no such functionality in Moodle core anyway). |
|
When a portfolio is graded, it should get unlocked anyway by way of this functionality we’re talking about so I don’t think that is an issue. I think it’s more concerning for cases where a student submits their portfolio and it doesn’t get graded for some reason. The portfolio they submitted would then be indefinitely locked… unless they figured out how to revoke their submission by selecting “no page.” It might be nice to make that more up-front in the user interface. Instead of a user having to figure out they need to resubmit with a “no page,” there could be a button that says “revoke submission.” Here’s a rough idea of the workflow: Instructor creates mahara assignment and chooses whether or not the portfolio should be locked on submission (A) or remain unlocked (B) If (A)
a. Student decides they want their portfolio unlocked BEFORE assignment deadline has passed b. Student decides they want their portfolio unlocked AFTER assignment deadline has passed (maybe because the instructor never graded it, leading to an indefinitely locked portfolio)
If (B)
-Tony From: Ruslan Kabalin [mailto:notifications@github.com] OK, then for this stage I will implement per-assignment unlocking setting to make functionality identical to assignfeedback. Regarding unlocking page by student - well, if submission has not been graded, it should be possible by selecting "no Page" (which will unlock previously submitted Page). If work has been graded, I am not sure it would be a good idea to allow student to revoke submission (no such functionality in Moodle core anyway). — |
|
@upats The problem with "Revoke" button is that the same submission may contain a combination of different submission types, e.g. file, text and Mahara altogether. While we know exactly what should happen on revoking Mahara portfolio, it is not clear what other plugins need to do - does entire submission needs to be rolled back to the draft state including all other parts? Or perhaps deleted? And how this feature needs to behave when assignment setting does not permit "editing" after submission? This is a relatively complex feature that depends on many aspects in assignment plugin and, therefore, if implemented, it needs to be in Moodle core and utilised in submission plugins via callbacks. We can't implement it just for Mahara assignment unfortunately, if we talk about proper implementation of the feature (rather than a hack), we heavily rely on Moodle mod_assign API in what can be done and at what stage. For now I think the best way to improve "revoking" is to make a more clear language string on submission page stating that "no page" means revoke if other page has been submitted. Anyhow, implemented this way or another, the best place for further discussion of revoking functionality should be a separate tracker issue ;) |
|
Working on per-assignment unlocking at the moment. I am thinking that the best way would be to extend existing settings. We currently have "Lock submitted pages" that has No/Yes (0/1) settings. I want to modify options as follows (for both global settings and per-assignment):
During plugin upgrade, I will need to update per-assignment setting for those assignment that had feedback enabled and set their 'lock' setting to 2 (others should just work with current settings). And then (perhaps separate and the latest upgrade routine) decline to upgrade unless feedback plugin is uninstalled :)) This way current settings are preserved and behaviour for existing assignments will remain the same. |
|
The above has been implemented: lucisgit@1c7ab8b @agwells What would be the best plan of merging it? Perhaps I will create another branch for 28 and send two pull requests (for 27 and 28), so that you would review it properly before merging. May be it is time to spin-off 29 branch and make release? Then the release can be mentioned in wiki and assignfeedback_mahara plugin README.md, that installation of assignfeedback_mahara is no longer required. May be some release notes that assignfeedback_mahara needs to be removed during upgrade (if removed prior upgrade, then we will not be able to upgrade assignments that had feedback enabled to make them "Yes, unlock page after grading"). |
|
Since Moodle 2.9 has now been released, we may as well make a moodle29 branch. Sure, the idea of sending pull requests sounds good. Does this change require different code for 2.7, 2.8, and 2.9, or will it cherry-pick cleanly from one version to another? |
|
@agwells, it should be just a matter of cherry-picking for 2.8 at least. Shame, I have not tested it on 2.9 yet, any chance you could do that while creating 2.9 branch? |
|
moodle28-eventunlocking works perfectly on Moodle 2.9, we are using it on production. |
|
Plugin code that works on Moodle 2.7, 2.8, 2.9. https://github.com/lucisgit/moodle-assignsubmission_mahara/commits/master Perhaps we need to stop differentiating between Moodle versions? See #16 |
|
Hi, I know you guys have been working on this issue for quite a while. In Moodle, you can evaluate students with a "marking workflow" which adds several statuses to each assessment within a Moodle assignment. Currently, when a Mahara page is submitted within a Moodle assignment with the workflow option activated, the Mahara page will be release when a teacher or a TA changes the status of the "marking workflow" to anything else than "Not marked". Here's a screenshot of the workflow menu when activated.
Here's an example that happened to us at University of Montreal. A TA wanted to confirm the grade of a student with his/her professor. He/she selected the "In review" status to make sure that they know which student was to be reviewed (there were about 170 students in total). Unfortunately, when he/she saved, the student's page was released in Mahara, making the student think that he/she could modify his/her page. They only found out later in the day because one of the student asked if this was normal. In this case, it was a serious issue. In our opinion, the page should be released only when the last stage of the workflow is selected: "Released". Frankly, we didn't expect this because we didn't think that members of a certain faculty would use a combination of the "Marking workflow" and the "Mahara assignment plugin". Just thought I let you guys know about this as I didn't see any concrete example so far in the discussion. Regards, Melvin |
|
Hello @MelvRom, "Marking workflow" support has been implemented in the latest plugin release (1.2-mdl2.7+), is it the one you are using? |
|
Using events for unlocking behaviour has been implemented in 1.2-mdl2.7+. Issue can be marked as closed. |
|
Yeah, I guess we never actually filed a separate Github issue about workflow. And I didn't mention it specifically in the 2.7 readme (except a footnote at the end about it being funded by Lancaster). But if you look closely at Ruslan's initial comments on this issue, the impetus to switch from the feedback plugin to events, was in order to support marking workflow. |
|
The separate issue was recorded in MaharaProject/moodle-assignfeedback_mahara#1, as unlocking was assignfeedback_mahara plugin job. |
|
Can you update the README to mention that we support marking workflow? I don't know enough about marking workflow to feel comfortable saying what we do with it. :) |
|
@agwells It is mentioned already, see https://github.com/MaharaProject/moodle-assignsubmission_mahara#a-little-info-about-what-it-does and at the top section before Installation as well. |
|
Hi guys, Great! This should fix our problem. Thank you for your quick answers! Melvin |
|
@kabalin Excellent. I've gone ahead and added a bit workflow to the feature list on the Moodle Plugin site as well, and added a link back to the github readme for more details, under the "Usage" section. https://moodle.org/plugins/view/assignsubmission_mahara |
|
Thanks @agwells! What I am thinking, release notes in Moodle plugin page (https://moodle.org/plugins/pluginversion.php?id=9707), should really be a release notes, not a copy of Readme - similar to what I do for this plugin: https://moodle.org/plugins/pluginversion.php?id=9104 What is in repo Readme, should be in Moodle plugin description (already there actually). |
|
@MelvRom Glad it works for you! If there are any issues, please open new bug report. Enjoy ;) |
|
I can update release notes in the latest release accordingly, no problem, if you are generally agree with proposal @agwells. |
|
@kabalin I like the idea. Release notes are always super helpful to regular users who might not know to look at github. |
|
Sounds good to me too. |
As it has been stated in the corresponding bug in assignfeedback plugin, unlocking mechanism implementation using feedback plugin does not respect marking workflow states and unlock pages when they should remain locked. The reason is simple - feedback plugin is designed to capture feedback from grading teacher and being triggered on grading events only. Assign plugin events are believed suit better for purpose of unlocking pages and collections on Mahara, as they allow to track both grading and workflow states (and potentially other related events).
One thing that has been implemented in assignfeedback plugin, but is difficult to reach using events is passing over outcomes data along with unlocking. However, there are two things about outcomes - one is that outcomes are not enabled in Moodle by default, another is that on Mahara core those outcomes data is passed to artefacts, but no core artefacts are using it for anything. There is actually a third thing, the way how outcomes are retrieved in feedback plugin is hacky, plugin is trying to determine the updated outcomes state by looking at passed POST parameters as there are no relevant data objects are passed to feedback to use for outcomes retrieving.
Having discussed this in #mahara irc channel, the decision was to consider moving away from using feedback plugin for unlocking and rely entirely on events, which would allow to perform unlocking on various states, such as grading or releasing marks to student if workflow is in use. Outcomes needs to be considered as separate data, and, if needed, passing this data to Mahara needs to be implemented as a separate call (not as a part of unlocking).
The text was updated successfully, but these errors were encountered: