project: Moodle
summary: META: Events and Logging follow ups
description: All forgotten things and small improvements left from introducing of Events and Logging API in 2.6-2.7

1.summary: When a course is deleted too much records are deleted from mdl_log. There is no clue left the course existed
description: When a course is deleted all the records in the table mdl_log related to that course are deleted. That means you have no way to know who deleted the course (there may be several course teachers), when and by whom the course was created, and even whether the course once existed. I think it could be a security issue because an administrator should be able to trace course creation a deletion. You can see how the function "remove_course_contents" (lib/moodlelib.php ) deletes all the records from mdl_log calling function "delete_records", and how the function "delete_course" doesnt insert any record in mdl_log after deleting the course.
2.summary: Create a Mongo DB store for logging
description: The logging apis support stores for both reading and writing into backends which do not directly understand sql. This issue deals with creating a Mongo DB store as proof of concept. This will require writing a parser for sql predicate emulation, that is required by our reports. Ps:- This store is supposed to be only a proof of concept and wont be a part of core. However we can consider to include the parser as a part of core.
3.summary: Add a trait for parsing the simplified sql used for readers
description: Any NoSQL store wanting to implement the sql_select_reader interface will need to have a simple SQL parser to break up statements into operators, keywords, groupings etc. We should implement this in core to make it easy for plugin authors to implement NoSQL stores. The other benefit of implementing it in core, is that it could possibly be used to unit test the SQL being sent by reports. Ie maybe each report can have a unit test where it queries a test reader using this trait that explodes when it doesnt understand the SQL syntax in the report.
4.summary: Use MUC to get user and course information in log and livelog reports
description: With use of new logging infrastructure, users and course are not joined in SQL and fetched separately and stored in array. It would be nice to use MUC to avoid performance issues.
5.summary: Get CRUD and edulevel options from log_store
description: CRUD action and edulevel log filtering options should be returned from log_store. Currently this is hard-coded in report_log::get_actions() and report_log::get_edulevel_options(). It would be nice if this is returned from log_manager or respective log_store, so it is consistently used.
6.summary: Dont show report links to user if respective reader is not enabled
description: If report only works with specific reader and that reader is not enabled or non of the readers are enabled then dont show report link to user.
7.summary: validate_data for events should be called only with debugdeveloper
description: Calling validate_data() is not required for production installs, it is a developer thing and should be done only when debug developer is on.
8.summary: Extend the base method get_explanation in each class to return a translatable string.
description: The event list report requires an explanation of what the event does. At the moment it is filtering the docblock of the event class, but this is only a short term solution and must be replaced with a string that can be translated. Each event will have to extend the method "core\event\base::get_explanation"
9.summary: "Other" parameters should be defined in a method similar to webservices
description: To properly document each class (like web services) each of the "other" parameters should be defined, possibly in a new method. Reasons for this improvement: This will give some certainty to developers creating observers listening to these events. Validation can be done in the base class instead of event specific validations for the other properties. The event list report can retrieve this information is a satisfactory way.
10.summary: Link the reports log and log live to the event list report detail
description: Each log entry could have a link to the detail page of the event list report. This could allow people looking at logs to get additional details about the event. Looking at those pages, an icon would probably be the best solution. This will probably mean that the information will have to be returned in a modal form.
11.summary: Create traits for refactoring event triggers
description: Event triggers can be quite lengthy. We can do a lot of refactor using proper methods here. For example in many places we have $cm, which is used to create the event. A method like:- code public static function create_from_cm($cm, $other = array()) code Would simplify the trigger a lot. Such methods could be reused among various events and a trait for each of these methods would make life much easy. Other possible methods:- create_from_module_instance() create_from_user() create_from_chapter() (for books) We are already doing this in a few events (Example books) and all the events are duplicating the methods in their definitions.
12.summary: Have the details of the event in the events list pop up on the same page.
description: At the moment when clicking on an event it takes you to another page with the details there. If you go back there is a chance of the filtering information being lost. A pop up on the main event list table would be a better solution. This could then also be used when linking event details from the logs.
13.summary: Write documentation on how to write a logstore
description: Write documentation on how to write a logstore for the logmanager distributed in core
14.summary: Write documentation on how to write a log manager
description: Write documentation on how to write a logmanager
15.summary: Remove unnecessary the in event descriptions.
description: In the references to the id were changed to just use id (eg. "The user with the id 2" became "The user with id 2".). However, there is still a mention of the course module id in the descriptions. These can be changed to remove the unnecessary the.
16.summary: Event user_enrolment_deleted/updated should have enrolment method in description
description: It would be useful in the description.
17.summary: Save search word in mod_glossary cm viewed event
description: When searching the glossary the "Course module viewed" event is triggered, the url contains mode=search but does not contain the search word
18.summary: Deprecate log-retrieving functions from datalib.php in 2.8
description: Some functions that are not used any more but we forgot to deprecate in 2.7: - get_logs_userday - get_logs_usercourse - get_logs
19.summary: Updating a comment triggers a comment_deleted event.
description: Create a wiki. Add a comment, saving with the "Save comment" button. Edit the comment by using the cog edit and saving with the "Save comment" button. View /report/log/index.php and click Get these logs. Notice that there is a Comment deleted event. I am guessing there may be something weird in the API which instead of updating a comment, creates a new one and deletes the old one. Needs investigating.
20.summary: Reimplement access to log table in auth/mnet/auth.php
description: Currently this plugin uses the legacy logging table. It needs to be upgraded to use the new logging API.

Below is an instruction that describes a task, paired with an input that provides an epic with this format: 
"project": "Name of the project" 
"summary": "Summary of the epic user story" 
"description": "Description of the epic user story". Write a response that appropriately completes the request.### Instruction:
Break this epic user story into smaller tasks to help the developers understand the epic better, you can divide this epic into as much as you want depending on the complexity of the epic.
### Input:
project: Moodle
summary: META: Events and Logging follow ups
description: All forgotten things and small improvements left from introducing of Events and Logging API in 2.6-2.7

### Response:
1.summary: When a course is deleted too much records are deleted from mdl_log. There is no clue left the course existed
description: When a course is deleted all the records in the table mdl_log related to that course are deleted. That means you have no way to know who deleted the course (there may be several course teachers), when and by whom the course was created, and even whether the course once existed. I think it could be a security issue because an administrator should be able to trace course creation a deletion. You can see how the function "remove_course_contents" (lib/moodlelib.php ) deletes all the records from mdl_log calling function "delete_records", and how the function "delete_course" doesnt insert any record in mdl_log after deleting the course.
2.summary: Create a Mongo DB store for logging
description: The logging apis support stores for both reading and writing into backends which do not directly understand sql. This issue deals with creating a Mongo DB store as proof of concept. This will require writing a parser for sql predicate emulation, that is required by our reports. Ps:- This store is supposed to be only a proof of concept and wont be a part of core. However we can consider to include the parser as a part of core.
3.summary: Add a trait for parsing the simplified sql used for readers
description: Any NoSQL store wanting to implement the sql_select_reader interface will need to have a simple SQL parser to break up statements into operators, keywords, groupings etc. We should implement this in core to make it easy for plugin authors to implement NoSQL stores. The other benefit of implementing it in core, is that it could possibly be used to unit test the SQL being sent by reports. Ie maybe each report can have a unit test where it queries a test reader using this trait that explodes when it doesnt understand the SQL syntax in the report.
4.summary: Use MUC to get user and course information in log and livelog reports
description: With use of new logging infrastructure, users and course are not joined in SQL and fetched separately and stored in array. It would be nice to use MUC to avoid performance issues.
5.summary: Get CRUD and edulevel options from log_store
description: CRUD action and edulevel log filtering options should be returned from log_store. Currently this is hard-coded in report_log::get_actions() and report_log::get_edulevel_options(). It would be nice if this is returned from log_manager or respective log_store, so it is consistently used.
6.summary: Dont show report links to user if respective reader is not enabled
description: If report only works with specific reader and that reader is not enabled or non of the readers are enabled then dont show report link to user.
7.summary: validate_data for events should be called only with debugdeveloper
description: Calling validate_data() is not required for production installs, it is a developer thing and should be done only when debug developer is on.
8.summary: Extend the base method get_explanation in each class to return a translatable string.
description: The event list report requires an explanation of what the event does. At the moment it is filtering the docblock of the event class, but this is only a short term solution and must be replaced with a string that can be translated. Each event will have to extend the method "core\event\base::get_explanation"
9.summary: "Other" parameters should be defined in a method similar to webservices
description: To properly document each class (like web services) each of the "other" parameters should be defined, possibly in a new method. Reasons for this improvement: This will give some certainty to developers creating observers listening to these events. Validation can be done in the base class instead of event specific validations for the other properties. The event list report can retrieve this information is a satisfactory way.
10.summary: Link the reports log and log live to the event list report detail
description: Each log entry could have a link to the detail page of the event list report. This could allow people looking at logs to get additional details about the event. Looking at those pages, an icon would probably be the best solution. This will probably mean that the information will have to be returned in a modal form.
11.summary: Create traits for refactoring event triggers
description: Event triggers can be quite lengthy. We can do a lot of refactor using proper methods here. For example in many places we have $cm, which is used to create the event. A method like:- code public static function create_from_cm($cm, $other = array()) code Would simplify the trigger a lot. Such methods could be reused among various events and a trait for each of these methods would make life much easy. Other possible methods:- create_from_module_instance() create_from_user() create_from_chapter() (for books) We are already doing this in a few events (Example books) and all the events are duplicating the methods in their definitions.
12.summary: Have the details of the event in the events list pop up on the same page.
description: At the moment when clicking on an event it takes you to another page with the details there. If you go back there is a chance of the filtering information being lost. A pop up on the main event list table would be a better solution. This could then also be used when linking event details from the logs.
13.summary: Write documentation on how to write a logstore
description: Write documentation on how to write a logstore for the logmanager distributed in core
14.summary: Write documentation on how to write a log manager
description: Write documentation on how to write a logmanager
15.summary: Remove unnecessary the in event descriptions.
description: In the references to the id were changed to just use id (eg. "The user with the id 2" became "The user with id 2".). However, there is still a mention of the course module id in the descriptions. These can be changed to remove the unnecessary the.
16.summary: Event user_enrolment_deleted/updated should have enrolment method in description
description: It would be useful in the description.
17.summary: Save search word in mod_glossary cm viewed event
description: When searching the glossary the "Course module viewed" event is triggered, the url contains mode=search but does not contain the search word
18.summary: Deprecate log-retrieving functions from datalib.php in 2.8
description: Some functions that are not used any more but we forgot to deprecate in 2.7: - get_logs_userday - get_logs_usercourse - get_logs
19.summary: Updating a comment triggers a comment_deleted event.
description: Create a wiki. Add a comment, saving with the "Save comment" button. Edit the comment by using the cog edit and saving with the "Save comment" button. View /report/log/index.php and click Get these logs. Notice that there is a Comment deleted event. I am guessing there may be something weird in the API which instead of updating a comment, creates a new one and deletes the old one. Needs investigating.
20.summary: Reimplement access to log table in auth/mnet/auth.php
description: Currently this plugin uses the legacy logging table. It needs to be upgraded to use the new logging API.
