This issue involves creating the moodlenet component in core and the key API(s) and backend functionality required to share specified LMS content to MoodleNet.

Requirements

1. This component will exist in core Moodle, so will require the following:
2. Main API class(es) to be located in a new lib/classes/moodlenet directory.
3. Appropriate update to lib/apis.json.

1. An API that, for a specified activity/resource and MoodleNet site, has the ability to send a Moodle backup (.mbz) of that resource (prepared by #4 below) to the MoodleNet site, using a single multipart request via Guzzle as per MoodleNet’s API specification.
2. In the above MoodleNet API call, the title will be the activity name (required) and description will be the activity description (if it exists, otherwise empty).
3. Ability to package a specified activity as a Moodle backup file, which contains the base activity content (ie no users or user data, grades etc). A proof of concept is available at MDL-75320. This requirement can be separated into its own issue if necessary to reduce scope on this issue.
4. The API method that is called to share the content to MoodleNet should return the resulting MoodleNet URL. When the relevant web service is implemented in a follow up issue, this will be used to provide the user with a link to the draft resource that has been created.
5. Logging to admin logs of all share attempts, including details of what was being shared and whether it was successful/failed.
6. The maximum file size supported by HQ MoodleNet is 1.2GB, so we need to ensure this is not exceeded before sending. Note: This may be configurable within MoodleNet instances (not clear whether it is yet), but there is currently no way to retrieve that information.
7. PHPUnit testing coverage.

Some considerations which should be factored in when naming/architecting relevant classes and methods:

1. The MoodleNet API spec is still a WIP, the endpoint URLs are subject to change (this is not a blocker, any changes can be made in a follow up).
2. In phase 2, it will also be possible to send a course backup (which includes specified activities within the course).
3. In phase 2 or later, we will not be limiting scope to sending as a backup, there may be other types, such as sending the raw file from a file resource (which would be the same as a backup without the MBZ generation step), or sending a URL instead of a file (which won’t require multipart).

User stories

This issue helps satisfy the following user story:

1. As a site admin, I can view a log of all content that has been shared (or attempted to be shared) from the LMS instance to MoodleNet, so I can ensure policies and licensing are adhered to.

Although this issue does not provide any functionality directly to teachers, it creates the framework to help satisfy the following user stories:

1. As a teacher, I can synchronously share a single activity/resource to MoodleNet as a Moodle backup file, so it is available for others to import into their Moodle courses.
2. As a teacher, I will be provided with a link to my draft resource on MoodleNet, so I can complete any additional metadata requirements and publish my resource.
3. As a teacher, I will be notified if an attempt to share to MoodleNet fails, so I can take appropriate action.
4. As a teacher, while I am waiting for my share to MoodleNet to complete, I will see multiple status updates, so I have a clear indication that the packaging and uploading of my resource is progressing.

Out of scope

1. Web services, they will be created in MDL-75933.
2. Checking we can reach the MoodleNet site before packaging and attempting to send the resource. This will be implemented in MDL-77297.
3. File cleanup, implemented by MDL-77295.
4. Logging for teachers’ information, covered by MDL-77296 (and won’t be visible to teachers in phase 1).