Moodle
  1. Moodle
  2. MDL-30290

External tool activity description not displayed on course page

    Details

      Description

      This is also reported as point B14 of http://docs.moodle.org/dev/IMS-LTI_consumer_module_review_2011-11

      I'm creating it now because blocks an existing QA test so should be fixed ASAP.

      Ciao

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            Chris Scribner added a comment -
            Show
            Chris Scribner added a comment - Code is in branch: https://github.com/scriby/moodle/tree/MDL-30290
            Hide
            Eloy Lafuente (stronk7) added a comment -

            Hi Chris,

            I've moved this from peer review (it's best used when "others" want to request review / approval from you, the component leader) to submit for integration (when you, the leader, decide something is ready to land, both own fixed bugs and reviewed from others).

            So then we, the integrators, review the code once again and it goes trough the complete process, ending with the fix included upstream.

            That way, the dev that did the fix is always correct in the tracker, and each person has its correct role.

            So, basically, you, as maintainer of the lti component will:

            • receive automatic inform of any ims-lti issue created (being set as default assignee).
            • fix issues and send them to integration
            • receive peer-requests from other devs and decide if the work requires more work or it's ok, so you'll send it to integration.

            Note that the "send to integration" step requires you to fill a bunch of info (repo, branch, diff) and testing instructions. If any of them is missing, surely you'll see your issues rejected immediately (not now, lol, don't worry, but after some weeks).

            I've updated the required fields for this issue myself (and will do for the rest of lti-ones existing until now, no problem). Just try to get used into the "send to integration" workflow step. As said, it's the one that you, as maintainer, will be using more.

            And let use the peer-review one for asking the you (others will ask you about ims-lti ones and or you will look periodically for ims-lti issues in "peer review requested" status). Of course, if, for example you fix one glossary issue (you are not maintainer of), you will use that workflow step to ask for peer-review to the glossary maintainer (me). But within your component, you're God (and good). You validate fixes from the rest (peer-review) and you send them and your own straight to integration review.

            Hope this clarifies a bit how each role is involved in the process... ciao

            Show
            Eloy Lafuente (stronk7) added a comment - Hi Chris, I've moved this from peer review (it's best used when "others" want to request review / approval from you, the component leader) to submit for integration (when you, the leader, decide something is ready to land, both own fixed bugs and reviewed from others). So then we, the integrators, review the code once again and it goes trough the complete process, ending with the fix included upstream. That way, the dev that did the fix is always correct in the tracker, and each person has its correct role. So, basically, you, as maintainer of the lti component will: receive automatic inform of any ims-lti issue created (being set as default assignee). fix issues and send them to integration receive peer-requests from other devs and decide if the work requires more work or it's ok, so you'll send it to integration. Note that the "send to integration" step requires you to fill a bunch of info (repo, branch, diff) and testing instructions. If any of them is missing, surely you'll see your issues rejected immediately (not now, lol, don't worry, but after some weeks). I've updated the required fields for this issue myself (and will do for the rest of lti-ones existing until now, no problem). Just try to get used into the "send to integration" workflow step. As said, it's the one that you, as maintainer, will be using more. And let use the peer-review one for asking the you (others will ask you about ims-lti ones and or you will look periodically for ims-lti issues in "peer review requested" status). Of course, if, for example you fix one glossary issue (you are not maintainer of), you will use that workflow step to ask for peer-review to the glossary maintainer (me). But within your component, you're God (and good). You validate fixes from the rest (peer-review) and you send them and your own straight to integration review. Hope this clarifies a bit how each role is involved in the process... ciao
            Hide
            Eloy Lafuente (stronk7) added a comment -

            Integrated, thanks!

            PS: I've added one extra commit with whitespace & comments cleanup.

            Show
            Eloy Lafuente (stronk7) added a comment - Integrated, thanks! PS: I've added one extra commit with whitespace & comments cleanup.
            Hide
            Eloy Lafuente (stronk7) added a comment -

            Works as expected, passing, thanks!

            Show
            Eloy Lafuente (stronk7) added a comment - Works as expected, passing, thanks!
            Hide
            Eloy Lafuente (stronk7) added a comment -

            Closing as fixed, many thanks for your effort!

            Note that the changes related to master (2.2beta) have been already sent upstream. But the stable ones will be part of next weeklies (Wed/Thu) as usual.

            Ciao

            Show
            Eloy Lafuente (stronk7) added a comment - Closing as fixed, many thanks for your effort! Note that the changes related to master (2.2beta) have been already sent upstream. But the stable ones will be part of next weeklies (Wed/Thu) as usual. Ciao

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: