Adding Eloy here as a watcher as this involves server-side part of the machinery.

The Moodle code itself is prepared for that. The response from the server is expected to provide URL to download as well as the URL to a page with more information about the plugin. See the fake.php example attached to MDL-20438 for the expected structure of the info. The 'download' URL is supposed to contain a link to the ZIP package with the plugin. The 'url' value is supposed to contain a link like the one Martin provided in the description.

I intentionally did not include any URL construction at the client side. All info is supposed to be returned by the server (which gives us more flexibility, should we ever need it).

Eloy, I believe an addition of at least the 'url' item should be pretty trivial. If you find time to implement it into your scripts, please feel free to re-assign this to yourself. Thanks in advance.

Oki, Updates API updated to:

• return the 'url' for each matching plugin version returned.
• consider "matching" those being the most recent per maturity (null maturity included). We were returning all before without any maturity grouping.
• avoid returning any null maturity and release information.
• avoid returning any information about plugins not having any "match".

Ciao

Self-integrated, self-thanks!
(and thanks to David for all the details support).

Passing. A shiny "More info ..." link appears leading to the details on the available update. Thanks Eloy for another great job. Yay!

Woot - so glad that no Moodle changes were required!

Next problem: MDLSITE-1819

Closing this as fixed, changes are now available upstream.

Big thanks!