Moodle
  1. Moodle
  2. MDL-41101

Replace existing add_to_log calls for mod_assign

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.6
    • Fix Version/s: 2.7
    • Component/s: Libraries, Logging
    • Labels:
    • Story Points (Obsolete):
      40
    • Sprint:
      BACKEND Sprint 12

      Description

      Replace the existing add_to_log calls for mod_assign.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            CiBoT added a comment -
            Show
            CiBoT added a comment - Results for MDL-41101 Remote repository: https://github.com/markn86/moodle.git Remote branch MDL-41101 _master to be integrated into upstream master Executed job http://integration.moodle.org/job/Precheck%20remote%20branch/2624 Details: http://integration.moodle.org/job/Precheck%20remote%20branch/2624/artifact/work/smurf.html
            Hide
            Adrian Greeve added a comment -

            [Y] Syntax
            [Y] Whitespace
            [-] Output
            [Y] Language
            [-] Databases
            [*] Testing (instructions and automated tests)
            [-] Security
            [-] Documentation
            [Y] Git
            [-] Third party code
            [Y] Sanity check

            Hello Mark,

            To me everything looks fine.

            The usual comments:

            1. Your updates to the different mod_assign classes extends your new class called base. I know that you like to minimise the amount of code that you have to write, but I think that it would be preferable to write out the full path here so that people checking out the function don't have to hover over, or click on the extended class, to see what the parent class is.
            2. mod/assign/classes/event/submission_status_viewed.php
              • No 'other' documentation for 'assignid'
              • Also no validation for this variable.
            3. No testing instructions yet.

            That's it, thanks.

            Show
            Adrian Greeve added a comment - [Y] Syntax [Y] Whitespace [-] Output [Y] Language [-] Databases [*] Testing (instructions and automated tests) [-] Security [-] Documentation [Y] Git [-] Third party code [Y] Sanity check Hello Mark, To me everything looks fine. The usual comments: Your updates to the different mod_assign classes extends your new class called base. I know that you like to minimise the amount of code that you have to write, but I think that it would be preferable to write out the full path here so that people checking out the function don't have to hover over, or click on the extended class, to see what the parent class is. mod/assign/classes/event/submission_status_viewed.php No 'other' documentation for 'assignid' Also no validation for this variable. No testing instructions yet. That's it, thanks.
            Hide
            Mark Nelson added a comment -

            Thanks Adrian,

            1) I don't really think this is necessary. I will see what integrators say.
            2) Thanks, done.
            3) Done.

            Submitting for integration.

            Cheers!

            Show
            Mark Nelson added a comment - Thanks Adrian, 1) I don't really think this is necessary. I will see what integrators say. 2) Thanks, done. 3) Done. Submitting for integration. Cheers!
            Hide
            Mark Nelson added a comment -

            Sorry Adrian, I just found two more add_to_log calls in the offline plugin that were not replaced. Can you review the last two commits? Thanks.

            Damyon - I am happy to squash these once you approve but I feel in order to review them it makes it MUCH easier to review each commit separately - that way you can ignore all the unrelated code.

            Show
            Mark Nelson added a comment - Sorry Adrian, I just found two more add_to_log calls in the offline plugin that were not replaced. Can you review the last two commits? Thanks. Damyon - I am happy to squash these once you approve but I feel in order to review them it makes it MUCH easier to review each commit separately - that way you can ignore all the unrelated code.
            Hide
            CiBoT added a comment -

            Results for MDL-41101

            Show
            CiBoT added a comment - Results for MDL-41101 Remote repository: https://github.com/markn86/moodle.git Remote branch MDL-41101 _master to be integrated into upstream master Executed job http://integration.moodle.org/job/Precheck%20remote%20branch/2685 Error: The MDL-41101 _master branch at https://github.com/markn86/moodle.git exceeds the maximum number of commits ( 16 > 15)
            Hide
            Mark Nelson added a comment -

            I am submitting this for integration. Please review the last two commits ASAP Adrian as it is code freeze this week. If you find an issue simply let me know and I will fix it.

            Show
            Mark Nelson added a comment - I am submitting this for integration. Please review the last two commits ASAP Adrian as it is code freeze this week. If you find an issue simply let me know and I will fix it.
            Hide
            Adrian Greeve added a comment -

            I don't see any major problems with the two additional commits. Please continue on Sir.

            Show
            Adrian Greeve added a comment - I don't see any major problems with the two additional commits. Please continue on Sir.
            Hide
            CiBoT added a comment -

            Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!

            Show
            CiBoT added a comment - Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!
            Hide
            Marina Glancy added a comment -

            Hi Mark, another great job on converting logs!

            Needs couple more touches:
            1. First commit should have AMOS commands to move strings, even though it's dev branch
            2. You do not need to pass "'userid' => $USER->id," to the events, it is done automatically
            3. You do not need assignment id in 'other' - please use contextinstanceid
            4. Please deprecate function assign::add_to_log() and remove all usages. The code for default URL should be copied to the function base::set_legacy_logdata()

            $addtolog = $this->add_to_log('view feedback', $logmessage, '', true);
            $event->set_legacy_logdata($addtolog);
            

            needs to be replaced with

            $event->set_legacy_logdata(array('view feedback', $logmessage, '', true));
            

            5. Do not pass get_string() to the legacy log data, use new lang_string(). If legacy logging is not enabled (which is by default), we won't need to retrieve a string then.
            6. You have several commits with the same message "MDL-41101 mod_assign: replaced 'view' add_to_log call with an event"
            7. Please make sure that you mark with edulevel PARTICIPATING only events that are interesting for Participation report. See the list returned in functions assign_get_view_actions() and assign_get_post_actions(). Keep in mind that those functions may not be 100% correct. Rajesh Taneja may be kind enough to consult on those.

            Thanks

            Show
            Marina Glancy added a comment - Hi Mark, another great job on converting logs! Needs couple more touches: 1. First commit should have AMOS commands to move strings, even though it's dev branch 2. You do not need to pass "'userid' => $USER->id," to the events, it is done automatically 3. You do not need assignment id in 'other' - please use contextinstanceid 4. Please deprecate function assign::add_to_log() and remove all usages. The code for default URL should be copied to the function base::set_legacy_logdata() $addtolog = $this->add_to_log('view feedback', $logmessage, '', true); $event->set_legacy_logdata($addtolog); needs to be replaced with $event->set_legacy_logdata(array('view feedback', $logmessage, '', true)); 5. Do not pass get_string() to the legacy log data, use new lang_string(). If legacy logging is not enabled (which is by default), we won't need to retrieve a string then. 6. You have several commits with the same message " MDL-41101 mod_assign: replaced 'view' add_to_log call with an event" 7. Please make sure that you mark with edulevel PARTICIPATING only events that are interesting for Participation report. See the list returned in functions assign_get_view_actions() and assign_get_post_actions(). Keep in mind that those functions may not be 100% correct. Rajesh Taneja may be kind enough to consult on those. Thanks
            Hide
            CiBoT added a comment -

            Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

            Show
            CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
            Hide
            CiBoT added a comment -

            Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

            Show
            CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
            Hide
            Mark Nelson added a comment -

            Hey Marina,

            Thanks for the review.

            1. Done. I didn’t actually realise this feature existed until I did a grep in the git history! Nice.
            2. Done.
            3. That gives the course module id, not the id of the row in the assign table. Why do we need to remove it?
            4. The add_to_log function creates a rather large array with the parameters passed. I would need to create another function to do the same thing. Personally I don’t think there is an issue keeping this function. If someone is to use it and it then calls the Moodle library’s add_to_log function then that will throw a debugging message. The last parameter passed to the assignment’s add_to_log function specifies whether we should return the array or not, so in this case it is true, so is returned rather than calling the deprecated add_to_log.
            5. Done, though tbh I don't really see this as a huge issue. The strings are cached, so performance improvements are negligible (or am I wrong?)
            6. Renamed the commits to distinguish which ‘view’ actions they were.
            7. I have changed a couple of them, but did not know it had to be the exact actions that are mentioned in those functions. I mean, what about new events. For example, the event submission_confirmation_form_viewed to me seems like it would be participating. Is it not?

            Show
            Mark Nelson added a comment - Hey Marina, Thanks for the review. 1. Done. I didn’t actually realise this feature existed until I did a grep in the git history! Nice. 2. Done. 3. That gives the course module id, not the id of the row in the assign table. Why do we need to remove it? 4. The add_to_log function creates a rather large array with the parameters passed. I would need to create another function to do the same thing. Personally I don’t think there is an issue keeping this function. If someone is to use it and it then calls the Moodle library’s add_to_log function then that will throw a debugging message. The last parameter passed to the assignment’s add_to_log function specifies whether we should return the array or not, so in this case it is true, so is returned rather than calling the deprecated add_to_log. 5. Done, though tbh I don't really see this as a huge issue. The strings are cached, so performance improvements are negligible (or am I wrong?) 6. Renamed the commits to distinguish which ‘view’ actions they were. 7. I have changed a couple of them, but did not know it had to be the exact actions that are mentioned in those functions. I mean, what about new events. For example, the event submission_confirmation_form_viewed to me seems like it would be participating. Is it not?
            Hide
            Marina Glancy added a comment -

            Hi Mark,
            3. yes I realised that later too. Though I still think that it is overloading of the log table, it's up to you whether to keep it or not. Event observers are still able to retrieve it as $PAGE->cm->instance
            4. at the moment it is just confusing and difficult to follow code. This code needs to be performed in your mod_assign\event\base::set_legacy_logdata(). Since the function in mod_assign may be called by plugins still, it should remain but have @deprecated tag and have an issue to remove it in 2.9. But you are right, there is no need to call debugging there because it will be called from add_to_log anyway. Don't forget that all assign plugins will be copy-pasting your event-calling code so we should make sure that they don't copy-paste the call to the function we want to remove soon.
            7. I noticed that there is way to many events in assign. I think it will be fair to mark such actions with edulevel OTHER even though they look like PARTICIPATING. Maybe put a comment there we've chosen this level because we don't want Participation report to show this event

            Show
            Marina Glancy added a comment - Hi Mark, 3. yes I realised that later too. Though I still think that it is overloading of the log table, it's up to you whether to keep it or not. Event observers are still able to retrieve it as $PAGE->cm->instance 4. at the moment it is just confusing and difficult to follow code. This code needs to be performed in your mod_assign\event\base::set_legacy_logdata(). Since the function in mod_assign may be called by plugins still, it should remain but have @deprecated tag and have an issue to remove it in 2.9. But you are right, there is no need to call debugging there because it will be called from add_to_log anyway. Don't forget that all assign plugins will be copy-pasting your event-calling code so we should make sure that they don't copy-paste the call to the function we want to remove soon. 7. I noticed that there is way to many events in assign. I think it will be fair to mark such actions with edulevel OTHER even though they look like PARTICIPATING. Maybe put a comment there we've chosen this level because we don't want Participation report to show this event
            Hide
            Mark Nelson added a comment -

            Thanks,

            3) I am leaving them as I am using them in the description and I honestly don't see any harm.
            4) Ok, done. One issue was that the event mod_assign\event\assessable_submitted was extending the class core\event\assessable_submitted (which imo is a useless class). I had to change the mod_assign\event\assessable_submitted class slightly to extend the base class I introduced.
            7) I am still not convinced by this. Seems strange to mark an event as other when the use is obviously participating. Rajesh Taneja can you please look at the diff quickly and just view the 'edulevel' for the events and see if you think they are appropriate? Thanks mate.

            Show
            Mark Nelson added a comment - Thanks, 3) I am leaving them as I am using them in the description and I honestly don't see any harm. 4) Ok, done. One issue was that the event mod_assign\event\assessable_submitted was extending the class core\event\assessable_submitted (which imo is a useless class). I had to change the mod_assign\event\assessable_submitted class slightly to extend the base class I introduced. 7) I am still not convinced by this. Seems strange to mark an event as other when the use is obviously participating. Rajesh Taneja can you please look at the diff quickly and just view the 'edulevel' for the events and see if you think they are appropriate? Thanks mate.
            Hide
            Rajesh Taneja added a comment -

            Hello Mark,

            Background about participation report:
            Previously, we used to have two functions (xxx_get_post_actions() and xxx_get_view_actions()) in all modules, which is used by participation report to filter log data. Now with new logging system we can get this information from edulevel. Combining edulevel with crud give us same results.
            Now participation report will consider (edulevel=LEVEL_PARTICIPATION && crud = r) as view action and (edulevel=LEVEL_PARTICIPATION && crud = ('c' || 'u' || 'd') ) as post actions.

            Coming back to this issue, following events have been marked as PARTICIPATION:

            1. assessable_submitted (c)
            2. feedback_viewed (r)
            3. statement_accepted (r)
            4. submission_confirmation_form_viewed (r)
            5. submission_duplicated (c)
            6. submission_status_viewed (r)
            7. submission_viewed (r)
            8. assessable_submitted (u)

            I my opinion following should not be LEVEL_PARTICIPATION:

            1. statement_accepted
            2. submission_confirmation_form_viewed
            3. submission_status_viewed (Not sure, but I think this is fired after submission has been submitted)

            Rest all seems fine, as they define participation.

            Show
            Rajesh Taneja added a comment - Hello Mark, Background about participation report: Previously, we used to have two functions (xxx_get_post_actions() and xxx_get_view_actions()) in all modules, which is used by participation report to filter log data. Now with new logging system we can get this information from edulevel. Combining edulevel with crud give us same results. Now participation report will consider (edulevel=LEVEL_PARTICIPATION && crud = r) as view action and (edulevel=LEVEL_PARTICIPATION && crud = ('c' || 'u' || 'd') ) as post actions. Coming back to this issue, following events have been marked as PARTICIPATION: assessable_submitted (c) feedback_viewed (r) statement_accepted (r) submission_confirmation_form_viewed (r) submission_duplicated (c) submission_status_viewed (r) submission_viewed (r) assessable_submitted (u) I my opinion following should not be LEVEL_PARTICIPATION: statement_accepted submission_confirmation_form_viewed submission_status_viewed (Not sure, but I think this is fired after submission has been submitted) Rest all seems fine, as they define participation.
            Hide
            Mark Nelson added a comment -

            Thanks Raj, made those changes as suggested. Pushing back for integration.

            Show
            Mark Nelson added a comment - Thanks Raj, made those changes as suggested. Pushing back for integration.
            Hide
            Marina Glancy added a comment -

            Hi Mark, thanks for changes.

            In half of the events you still use get_string(). In fact I don't quite understand why in mod_assign we need to explicitly call set_legacy_logdata and do not fill this data inside the event.

            Also the methods assign::format_submission_for_log(), assign::format_grade_for_log() and assign_plugin::format_for_log() (and the overriding methods) needs to be deprecated and the code inside it executed only if the legacy log is enabled (there are some DB queries there). At the same time the $submission and $grade objects need to be passed as event data when applicable (with proper setters and getters). In case of group submission you loose information about groupid in the new log. In case of grading you loose information about the actual grade in the log. It looks like new logging will actually contain LESS valuable information than legacy, which is not good.

            Show
            Marina Glancy added a comment - Hi Mark, thanks for changes. In half of the events you still use get_string(). In fact I don't quite understand why in mod_assign we need to explicitly call set_legacy_logdata and do not fill this data inside the event. Also the methods assign::format_submission_for_log() , assign::format_grade_for_log() and assign_plugin::format_for_log() (and the overriding methods) needs to be deprecated and the code inside it executed only if the legacy log is enabled (there are some DB queries there). At the same time the $submission and $grade objects need to be passed as event data when applicable (with proper setters and getters). In case of group submission you loose information about groupid in the new log. In case of grading you loose information about the actual grade in the log. It looks like new logging will actually contain LESS valuable information than legacy, which is not good.
            Hide
            Marina Glancy added a comment -

            P.S. maybe submission, grade and user can be passed as add_snapshot()

            Show
            Marina Glancy added a comment - P.S. maybe submission, grade and user can be passed as add_snapshot()
            Hide
            Mark Nelson added a comment -

            Hi Marina. if I deprecate these functions then I will just need to put the logic elsewhere, and a lot of the logic assumes we are calling within a mod_assign object. Where would you suggest I move the logic to?

            Show
            Mark Nelson added a comment - Hi Marina. if I deprecate these functions then I will just need to put the logic elsewhere, and a lot of the logic assumes we are calling within a mod_assign object. Where would you suggest I move the logic to?
            Hide
            Marina Glancy added a comment -

            You need to move as much as possible to your events classes (or mod_assign\event\base) and actively discourage assign plugins to use/overwrite existing log-related methods in classes assign and assign_plugin

            Show
            Marina Glancy added a comment - You need to move as much as possible to your events classes (or mod_assign\event\base) and actively discourage assign plugins to use/overwrite existing log-related methods in classes assign and assign_plugin
            Hide
            Marina Glancy added a comment -

            Mark, please note that all events must have @since tag, see MDL-45035

            Show
            Marina Glancy added a comment - Mark, please note that all events must have @since tag, see MDL-45035
            Hide
            Mark Nelson added a comment -

            Hi Marina,

            All newly introduced events now have a @since tag. Also, the get_string calls that were passed to set_legacy_eventdata (they were for events I did not create) have been changed to use 'new lang_string' instead.

            Do you think it would be possible to to leave deprecating assign::format_submission_for_log(), assign::format_grade_for_log() and assign_plugin::format_for_log() to another issue?

            Show
            Mark Nelson added a comment - Hi Marina, All newly introduced events now have a @since tag. Also, the get_string calls that were passed to set_legacy_eventdata (they were for events I did not create) have been changed to use 'new lang_string' instead. Do you think it would be possible to to leave deprecating assign::format_submission_for_log(), assign::format_grade_for_log() and assign_plugin::format_for_log() to another issue?
            Hide
            Petr Skoda added a comment - - edited

            we had some lengthy discussions today bout the best way to trigger the events in mod_assign, I have added a few commits on top of marks work to use new create_from_xx() helpers. The only remaining problem are the feedback and submission create/update events - I will work on them tomorrow...

            Show
            Petr Skoda added a comment - - edited we had some lengthy discussions today bout the best way to trigger the events in mod_assign, I have added a few commits on top of marks work to use new create_from_xx() helpers. The only remaining problem are the feedback and submission create/update events - I will work on them tomorrow...
            Hide
            Petr Skoda added a comment -

            finished, ready for review imo, I have decided to keep the subplugin events the way they are for now, they can be improved later...

            Show
            Petr Skoda added a comment - finished, ready for review imo, I have decided to keep the subplugin events the way they are for now, they can be improved later...
            Hide
            Marina Glancy added a comment -

            Hi Petr, I just ran the new David's test from MDL-44617 over your branch and got the error:

            Fatal error: Call to undefined method assignsubmission_onlinetext\event\submission_created::setAssign() in /home/marina/repositories/int_master/moodle/mod/assign/submission/onlinetext/locallib.php on line 209
            

            unfortunately behat tests don't cover every page in assign, can you make sure testing instructions include all pages and all calls to those events. Thanks.

            Show
            Marina Glancy added a comment - Hi Petr, I just ran the new David's test from MDL-44617 over your branch and got the error: Fatal error: Call to undefined method assignsubmission_onlinetext\event\submission_created::setAssign() in /home/marina/repositories/int_master/moodle/mod/assign/submission/onlinetext/locallib.php on line 209 unfortunately behat tests don't cover every page in assign, can you make sure testing instructions include all pages and all calls to those events. Thanks.
            Hide
            Petr Skoda added a comment -

            oops, I forgot to push my latest branch, fixed, sorry

            Show
            Petr Skoda added a comment - oops, I forgot to push my latest branch, fixed, sorry
            Hide
            Marina Glancy added a comment -

            and... this is integrated! Thanks Mark and Petr!

            Show
            Marina Glancy added a comment - and... this is integrated! Thanks Mark and Petr!
            Hide
            Damyon Wiese added a comment - - edited

            Notice: Trying to get property of non-object in /home/damyonw/Documents/Moodle/integration/master/moodle/mod/assign/submission/onlinetext/locallib.php on line 529
            Call Stack
            #	Time	Memory	Function	Location
            1	0.0000	233064	{main}( )	../view.php:0
            2	0.2452	8030144	assign->view( )	../view.php:53
            3	0.2452	8031032	assign->process_submit_other_for_grading( )	../locallib.php:434
            4	0.3177	9335096	assign->submit_for_grading( )	../locallib.php:4793
            5	1.0840	10866832	core\event\base->trigger( )	../locallib.php:4767
            6	1.0841	10867672	mod_assign\event\assessable_submitted->get_legacy_logdata( )	../base.php:637
            7	1.0842	10869312	assign->format_submission_for_log( )	../assessable_submitted.php:130
            8	1.0857	10884984	assign_submission_onlinetext->format_for_log( )	../locallib.php:5331
            

            To reproduce, login as admin and from the grading table choose "Submit for grading" for someone elses assignment (they must have a draft submission).

            Show
            Damyon Wiese added a comment - - edited Notice: Trying to get property of non-object in /home/damyonw/Documents/Moodle/integration/master/moodle/mod/assign/submission/onlinetext/locallib.php on line 529 Call Stack # Time Memory Function Location 1 0.0000 233064 {main}( ) ../view.php:0 2 0.2452 8030144 assign->view( ) ../view.php:53 3 0.2452 8031032 assign->process_submit_other_for_grading( ) ../locallib.php:434 4 0.3177 9335096 assign->submit_for_grading( ) ../locallib.php:4793 5 1.0840 10866832 core\event\base->trigger( ) ../locallib.php:4767 6 1.0841 10867672 mod_assign\event\assessable_submitted->get_legacy_logdata( ) ../base.php:637 7 1.0842 10869312 assign->format_submission_for_log( ) ../assessable_submitted.php:130 8 1.0857 10884984 assign_submission_onlinetext->format_for_log( ) ../locallib.php:5331 To reproduce, login as admin and from the grading table choose "Submit for grading" for someone elses assignment (they must have a draft submission).
            Hide
            Damyon Wiese added a comment -

            Unfailing - I cleared my cache and can't reproduce this now

            Show
            Damyon Wiese added a comment - Unfailing - I cleared my cache and can't reproduce this now
            Hide
            Damyon Wiese added a comment - - edited

            It looks very good - thanks for doing this nicely.

            I have 1 minor suggestion - and 1 big one.

            These 3 events deal with submission records that do not always belong to the current user, so it would be nice to put the userid in the relateduserid field when it is not the current user:
            mod/assign/classes/event/assessable_submitted.php
            mod/assign/submission/file/classes/event/assessable_uploaded.php
            mod/assign/submission/onlinetext/classes/event/assessable_uploaded.php
            (I'll attach a patch for this).

            Major one - when blind marking is enabled, we should set the anonymous flag on the event because it becomes trivial for a teacher to see whose submission they are marking.

            Show
            Damyon Wiese added a comment - - edited It looks very good - thanks for doing this nicely. I have 1 minor suggestion - and 1 big one. These 3 events deal with submission records that do not always belong to the current user, so it would be nice to put the userid in the relateduserid field when it is not the current user: mod/assign/classes/event/assessable_submitted.php mod/assign/submission/file/classes/event/assessable_uploaded.php mod/assign/submission/onlinetext/classes/event/assessable_uploaded.php (I'll attach a patch for this). Major one - when blind marking is enabled, we should set the anonymous flag on the event because it becomes trivial for a teacher to see whose submission they are marking.
            Hide
            Damyon Wiese added a comment -

            On the blind marking one - this is not actually any worse than 2.6 - so I'll create a new issue for it.

            Show
            Damyon Wiese added a comment - On the blind marking one - this is not actually any worse than 2.6 - so I'll create a new issue for it.
            Hide
            Damyon Wiese added a comment -

            MDL-45151 is the new issue for blind marking.

            Show
            Damyon Wiese added a comment - MDL-45151 is the new issue for blind marking.
            Hide
            Damyon Wiese added a comment -

            I am happy to pass this if someone checks and integrates the patch.

            The point of the patch is that without it, the assessable events do not list the user in the related user column in the log (which is useful when one person is e.g. editing someone elses submission).

            Show
            Damyon Wiese added a comment - I am happy to pass this if someone checks and integrates the patch. The point of the patch is that without it, the assessable events do not list the user in the related user column in the log (which is useful when one person is e.g. editing someone elses submission).
            Hide
            Petr Skoda added a comment -

            +1 for the relateduserid patch, marina: could you please pull it in? thx

            Show
            Petr Skoda added a comment - +1 for the relateduserid patch, marina: could you please pull it in? thx
            Hide
            Marina Glancy added a comment -

            patch integrated, thanks, sounds very reasonable

            Show
            Marina Glancy added a comment - patch integrated, thanks, sounds very reasonable
            Hide
            Damyon Wiese added a comment -

            OK - thanks for working on this. Passing the test.

            Show
            Damyon Wiese added a comment - OK - thanks for working on this. Passing the test.
            Hide
            Eloy Lafuente (stronk7) added a comment -

            Closing this as fixed, now it's part of Moodle upstream! Thanks!

            And in the end,
            it's not the years in your life that count,
            it's the life in your years.

            ~ Abraham Lincoln ~

            Show
            Eloy Lafuente (stronk7) added a comment - Closing this as fixed, now it's part of Moodle upstream! Thanks! And in the end, it's not the years in your life that count, it's the life in your years. ~ Abraham Lincoln ~

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Agile