Send report csv as attachment

[hamishdewe]

We want to be able to send data to users in a format that allows them to do their own filtering. Requiring them to log in to download the csv adds extra overhead to the task, so we want to attach the csv to the notification that they get sent.

[frumbert]

Is this feature still being considered?

[timhunt]

Can the Moodle message API handle attachments? If so, this would be a nice feature. Up-to-date pull requests welcome.

[Kemmotar83]

Hi Tim,

this plugin is great and implementing this feature could be very useful (in our university I would say necessary).

We have read the discussion made in the pull request #86 and, since the Message API still does not support temp files, I would say that the only solution is to use a Stored File.

Starting from that, we implemented the feature, paying attention to have all your automated tests working.
Before submitting a pull requests, we would like to know if you are still interested in this feature and then we would like to discuss with you about some implementation details (i.e. user private storage area vs plugin storage area).

Giorgio

[timhunt]

Thank you for considering contributing to this plugin.

I note that pull request #86 has been sitting around for over 2 years. If, 2 years ago, someone had made a change to Moodle core so that the file API could send temp files, then there would not be an issue any more.

On the other hand, just having the files sitting around in moodledate, but not in filedir, causes problems with some ways of setting up cloud hosting, so I am no longer so opposed to saving the reports with the file API, if that is implemented nicely.

I think that the key part of working out how to implement this is deciding exactly how things will be stored. Do you have a plan for how you will do it? It would be good to agree on that before you start writing code.

Thanks. Tim.

[brendanheywood]

hi @timhunt we have another client who is interested in sponsoring this. I've had a quick look at the PR and so to recap the approaches:

1) Core change to allow files

We do a tracker to allow the Message API in core to accept a raw file path as well as a stored_file object. It would seem like this is a breaking change to the output plugin api, BUT apart from the docs page I cannot see in core in the message API anything that prevents or expects the attachment to be a stored file. This is only softly checked in each output plugin.

I have looked at every output plugin in core and in the plugins dir here: https://moodle.org/plugins/browse.php?list=category&id=24

In my scan only 3 plugins actually do any handling of attachments, almost all just ignore them. Each would need a touch point to accept a real file, and output_email already immediately converts it to a temp raw file on disk anyway.

output/email/message_output_email.php <-- a couple lines in core

https://gitlab.com/adapta/moodle-message_msgraph/-/blob/main/message_output_msgraph.php#L74-76 <- copy paste from core email

Interestingly this plugin actually looks like it accepts raw files and handles them correctly already:

https://gitlab.com/moodle-local_mail/moodle-message_localmail/-/blob/main/message_output_localmail.php?ref_type=heads#L99-119

2) We swap report_customsql to store all reports in the File API

I'm not opposed to this but it seems like more effort than it should be. It's almost mostly done in the pr. The patch looks incomplete to clean up those files when the report is deleted for example.

**3) We use a temporary stored_file **

ie we store the file, send the message, and then delete the stored_file right away. It might not seem right at first but I can't see anything technically wrong with this approach so far and it seems to simplest to me without involving core changes. All message outputs are run instantly, and if they could be async then the output plugin would need to check that the file still exists either way, there is no guarantee that a stored_file exists into the future.

So @timhunt do you have a preference?