Introducing audit logging table for playlist videos and its cleanup cronjob

[ferishili]

This PR fixes #1257,

• Implemented PlaylistVideosAuditLog for tracking add, delete, and restore actions.
• Enhanced PlaylistVideos model to log actions during delete and store operations.
• It specifically checks the audit log in the discovery worker to make sure that if the playlist video was removed previously! this avoids force re-adding to playlist!
• Created a cronjob (OpencastPlaylistVideosAuditCleanup) to periodically clean up old audit log entries. (every 28 days)
• Added migration to create the oc_playlist_videos_audit_log table and schedule the cleanup task.

P.S. Feedback, suggestions, and arguments are very much appreciated!

[UPDATE]: the above mentioned description no longer applied, please see #1381 (comment)

[dennis531]

The code looks good and this patch solves the problem of the linked issue except the case above. However, I wonder if there is an easier way to solve this problem without a cronjob and a new database table.

For example, wouldn't it be sufficient to check whether the video has been added to the Stud.IP database for the first time, i.e. seen by Stud.IP?
If this is the case, the video would be added to the series playlist. Otherwise, the series would be ignored.

[ferishili]

However, I wonder if there is an easier way to solve this problem without a cronjob and a new database table.
For example, wouldn't it be sufficient to check whether the video has been added to the Stud.IP database for the first time, i.e. seen by Stud.IP?
If this is the case, the video would be added to the series playlist. Otherwise, the series would be ignored.

I would prefer to keep this logic within the plugin itself, especially when it comes to logging and event tracking, instead of relying on a higher-level recording mechanism (if I understood your suggestion correctly).
This is because we would also need to implement additional mechanisms for cleanup, such as removing related logs when a video or playlist is deleted.

Additionally, please note that the cronjob here is only used as a periodic cleanup task. So no need to be intimidated by it!

[ferishili]

Discussion:

• A simpler way has been discussed. and agreed upon:
  • We have to only do the addToCoursePlaylist in the discovery where the video is new! line 133!
  • So the observer needs to be removed as well!

[ferishili]

[UPDATE]: the change have been applied according to the discussion!

• No more Audit Log in favor of simplicity
• addToCoursePlaylist is no longer in an OpencastVideoSync event observer
• addToCoursePlaylist is called only when the video is newly discovered, which means that it only should cover the scheduling scenario!

[dennis531]

Thanks, Farbod. I like this solution! It works and the code looks great!