In order for a teacher to be able to view the send progress/status of activities and courses they have shared to MoodleNet, first there must be a way to store that data in a way that it can be easily processed and rendered in the UI. It is critical that this information is available before we are able to move sharing to MoodleNet from a synchronous process to asynchronous. Although MDL-75932 involves standard logging of shares to MoodleNet via admin logs, this issue relates to storing key information about what was shared and the current send status so that it can be easily fetched and presented to teachers in a MoodleNet share progress list (the page that makes this information available to teachers will be implemented in a follow up issue).

Requirements

1. Create a new share progress API in core\moodlenet, which in this phase will be responsible for storing and updating the information in the database. This will include recording basic information at the time the sharing is initiated (where the status is in progress), as well as performing updates to reflect changes in status (sent/error) and any pertinent information received from MoodleNet (such as the resource URL).
2. Implement the relevant database table to store the data in a forwards compatible way (see “DB tables” section below for more details).
3. Detailed "snapshots" of what has been shared (eg activity/course names) are not required (see out of scope section below).
4. Check if any of the data being stored constitutes user data, which may require some additions to the privacy provider.
5. During investigation of this issue, we should also look into other options that may be available, eg events hook when the "normal" logging is being called.

DB tables

To be compatible with planned functionality, this will need a table created to record the initial ID details of what is shared and by who, as well as some details from MoodleNet, as outlined below.

1. ID (PK, incremented).
2. Course ID.
3. LMS user ID that performed the share.
4. Share type (which can be an int that maps to a constant). For this phase, activity or course backup are the only options. It may be possible to use this to indicate URL or raw file in future as well if/when implemented.
5. LMS activity/resource ID (eg cmid) - this will need to be optional because it will remain empty for course sharing.
6. MoodleNet resource URL.
7. Time created timestamp (when the share is first requested).
8. Status (can map to an int constant for send statuses of error, in progress or sent status). This will initially be inserted as in progress when a share is first executed.

User stories

This issue does not directly address any user stories. It does however lay the initial foundation for future functionality which will address the following user story:

1. As a teacher, I need the ability to view the current send status of content I have recently shared to MoodleNet from the current Moodle site, so that I know when I can visit the respective MoodleNet draft to complete and publish the resource.

Out of scope

1. Implementing any UI to share this information with users (this is covered by other issues).
2. A way to fetch data from the API. This will be implemented alongside the UI.
3. Implementing system/admin level logging (which is already covered as part of the API).
4. Archiving or removing “old” entries. This will be linked to users viewing the content, so will be completed in a follow up.
5. Recording detailed information/names for activities/courses being shared. As the key focus is to keep a short term history of whether a share is in progress, sent or an error occurred, we can also assume that in most cases the content will still exist when the teacher views the status information, so a complete "snapshot" is unnecessary.
6. We also do not need to record which activities are included in a course share, it will be sufficient for us to be able to identify which course was shared (whether in whole or part).