Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-25831

Error sending a message when approving a course

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.0.2
    • Component/s: Course, Messages
    • Labels:
    • Database:
      Any
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE

      Description

      When a course is approved through the course request/arppvoal system:

      Coding error detected, it must be fixed by a programmer: Could not load preference message_provider_course_courserequestapproved_loggedin. Does the component and name you supplied to message_send() match a row in message_providers? Message providers must appear in the database so users can configure how they will be notified when they receive messages.

      More information about this error

      Debug info: blah
      Stack trace:
      line 126 of /lib/messagelib.php: coding_exception thrown
      line 4087 of /course/lib.php: call to message_send()
      line 4038 of /course/lib.php: call to course_request->notify()
      line 51 of /course/pending.php: call to course_request->approve()

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            tsala Helen Foster added a comment -

            Dan, thanks for your report.

            I've just tried rejecting a course request on http://qa.moodle.net/ and obtained an almost identical error.

            Coding error detected, it must be fixed by a programmer: Could not load preference message_provider_course_courserequestrejected_loggedin. Does the component and name you supplied to message_send() match a row in message_providers? Message providers must appear in the database so users can configure how they will be notified when they receive messages.

            Debug info: blah
            Stack trace:

            • line 126 of /lib/messagelib.php: coding_exception thrown
            • line 4087 of /course/lib.php: call to message_send()
            • line 4054 of /course/lib.php: call to course_request->notify()
            • line 78 of /course/pending.php: call to course_request->reject()

            Assigning to our messaging expert, Andrew. Please reassign if necessary.

            Show
            tsala Helen Foster added a comment - Dan, thanks for your report. I've just tried rejecting a course request on http://qa.moodle.net/ and obtained an almost identical error. Coding error detected, it must be fixed by a programmer: Could not load preference message_provider_course_courserequestrejected_loggedin. Does the component and name you supplied to message_send() match a row in message_providers? Message providers must appear in the database so users can configure how they will be notified when they receive messages. Debug info: blah Stack trace: line 126 of /lib/messagelib.php: coding_exception thrown line 4087 of /course/lib.php: call to message_send() line 4054 of /course/lib.php: call to course_request->notify() line 78 of /course/pending.php: call to course_request->reject() Assigning to our messaging expert, Andrew. Please reassign if necessary.
            Hide
            andyjdavis Andrew Davis added a comment -

            Ive implemented a fix for this. Should hopefully get integrated in the next sprint.

            git repository: git://github.com/andyjdavis/moodle.git
            branch: MDL-25831_course_approval_message
            diff URL: https://github.com/andyjdavis/moodle/compare/master...MDL-25831_course_approval_message

            While I was there I also made a change in course/request.php as it wasn't setting its context.

            Show
            andyjdavis Andrew Davis added a comment - Ive implemented a fix for this. Should hopefully get integrated in the next sprint. git repository: git://github.com/andyjdavis/moodle.git branch: MDL-25831 _course_approval_message diff URL: https://github.com/andyjdavis/moodle/compare/master...MDL-25831_course_approval_message While I was there I also made a change in course/request.php as it wasn't setting its context.
            Hide
            rescator Gerard Thouvenin added a comment -

            Hi,

            To fix this, I add 3 entries in table mdl_message_providers :

            id............name...........................component........capability
            ========================================================================
            10............courserequestapproved..........course...........NULL
            11............courserequestrejected..........course...........NULL
            12............courserequested................course...........NULL

            Don't enter the id, this field is auto-increment.

            Hope this help.

            Gérard

            Show
            rescator Gerard Thouvenin added a comment - Hi, To fix this, I add 3 entries in table mdl_message_providers : id............name...........................component........capability ======================================================================== 10............courserequestapproved..........course...........NULL 11............courserequestrejected..........course...........NULL 12............courserequested................course...........NULL Don't enter the id, this field is auto-increment. Hope this help. Gérard
            Hide
            samhemelryk Sam Hemelryk added a comment -

            Hi Andrew,

            All looks and appears to work well, there is one thing that needs to be checked out though.
            Now that we have tagged 2.0.1 I think we are meant to head back to the old system of incremented version numbers rather than the current date, we should ask Petr/Eloy to be sure once one of them is online (Petr is currently sick so likely Eloy).
            Ohh and did you realise you added a newline to the end of course/request.php?

            Cheers
            Sam

            Show
            samhemelryk Sam Hemelryk added a comment - Hi Andrew, All looks and appears to work well, there is one thing that needs to be checked out though. Now that we have tagged 2.0.1 I think we are meant to head back to the old system of incremented version numbers rather than the current date, we should ask Petr/Eloy to be sure once one of them is online (Petr is currently sick so likely Eloy). Ohh and did you realise you added a newline to the end of course/request.php? Cheers Sam
            Hide
            andyjdavis Andrew Davis added a comment -

            PM'd Eloy re version number. Wasnt aware we had a different versioning system. Its been the date as far back as I can remember but that may just be my memory.

            Also, removed the trailing newline. Thanks

            Show
            andyjdavis Andrew Davis added a comment - PM'd Eloy re version number. Wasnt aware we had a different versioning system. Its been the date as far back as I can remember but that may just be my memory. Also, removed the trailing newline. Thanks
            Hide
            poltawski Dan Poltawski added a comment -

            The old-style version numbers are like this:

                $version = 2007101580.00; // YYYYMMDD      = date of the 1.9 branch (don't change)
                                          //         X     = release number 1.9.[0,1,2,3,4,5...]
                                          //          Y.YY = micro-increments between releases

            Which is important when we branch (so 2.0.x can't get ahead of 2.1).

            Because 2.0 still hasn't been branched its not as critical to have this right now but there might be an argument to have this done by convention. By the way the integration team are going to have to be really careful about version numbers!

            Also this should be documented somewhere if its not already!!

            Show
            poltawski Dan Poltawski added a comment - The old-style version numbers are like this: $version = 2007101580.00; // YYYYMMDD = date of the 1.9 branch (don't change) // X = release number 1.9.[0,1,2,3,4,5...] // Y.YY = micro-increments between releases Which is important when we branch (so 2.0.x can't get ahead of 2.1). Because 2.0 still hasn't been branched its not as critical to have this right now but there might be an argument to have this done by convention. By the way the integration team are going to have to be really careful about version numbers! Also this should be documented somewhere if its not already!!
            Hide
            andyjdavis Andrew Davis added a comment -

            Had a chat with Eloy. He says the $version system is the same as ever. The integrator/committer upstream will update the $release one and that programmers dont need to worry about whatever black magic goes on there.

            Show
            andyjdavis Andrew Davis added a comment - Had a chat with Eloy. He says the $version system is the same as ever. The integrator/committer upstream will update the $release one and that programmers dont need to worry about whatever black magic goes on there.
            Hide
            andyjdavis Andrew Davis added a comment -

            git repository: git://github.com/andyjdavis/moodle.git

            branch: MDL-25831_course_approval_message

            diff URL: https://github.com/andyjdavis/moodle/compare/master...MDL-25831_course_approval_message

            Show
            andyjdavis Andrew Davis added a comment - git repository: git://github.com/andyjdavis/moodle.git branch: MDL-25831 _course_approval_message diff URL: https://github.com/andyjdavis/moodle/compare/master...MDL-25831_course_approval_message
            Hide
            poltawski Dan Poltawski added a comment -

            Hi Andrew,

            I'm reopening this as I think you need to submit a pull request in the PULL project to get this change merged.

            thanks

            Dan

            Show
            poltawski Dan Poltawski added a comment - Hi Andrew, I'm reopening this as I think you need to submit a pull request in the PULL project to get this change merged. thanks Dan
            Hide
            andyjdavis Andrew Davis added a comment -

            Thats weird. I'd have sworn Id seen a message saying the pull request had been accepted when I apparently haven't even submitted one...

            Thanks Dan for pointing this out. PULL-94

            Show
            andyjdavis Andrew Davis added a comment - Thats weird. I'd have sworn Id seen a message saying the pull request had been accepted when I apparently haven't even submitted one... Thanks Dan for pointing this out. PULL-94
            Hide
            tsala Helen Foster added a comment -

            Andrew, thanks for fixing this issue, and thanks everyone for your comments.

            Show
            tsala Helen Foster added a comment - Andrew, thanks for fixing this issue, and thanks everyone for your comments.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  21/Feb/11