Moodle
  1. Moodle
  2. MDL-30290

External tool activity description not displayed on course page

    Details

    • Rank:
      32635

      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

        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: