Any way to automate the ICS export?

[embeh]

It is great there is the iCalendar .ics export, thank you!
Now we would like to automate the iCalendar .ics export, either through a cURL request or directly on the backend, in order to run it every 30 minutes to automatically add them to other calendaring systems.

One way to do so would be to be able to configure certain rooms/areas to be 'public' such that an unauthenticated POST request to report.php could be allowed to get the data.

Another way would be some kind of cronjob on the server that would produce such an .ics file, directly from the database?

[campbell-m]

You should be able to do this by running report.php from a cron job. See the file help_report.html. However I haven't tested this for a while, so if I get time I might try and give it a go over the weekend.

[embeh]

Thanks for looking into this!
It never occurred to me to run report.php locally, i.e. on the server...

If this could work by sending a GET request to report.php it would be even better, as many calendar systems allow to pull an ICS file from some other source at certain intervals.

When I try to send a request via HTTP, I am redirected to the login page.

Same for running it via the command line (the output is the HTML to log in). $auth['deny_public_access'] is set to false in the config. Edit: never mind, found the setting $allow_cli = true

[campbell-m]

Yes, a cron job of the sort

/usr/local/bin/php /home/xxxx/public_html/book/report.php output_format=2 > /home/xxxx/public_html/book/report.ics

seems to work, but I agree that a REST API would be better. See also Issue #3636 .

[embeh]

Got the cronjob working, thanks!

Regarding REST - it would be better IMO if MRBS could simply provide a normal HTTP URL for downloading the current .ics file. With that, most normal calendar clients could directly download it. Thunderbird, for example, allows you to use a "https://yourserver/download.php" URL as source for a new calendar, together with a poll frequency (e.g. 30 minutes). See https://support.mozilla.org/en-US/kb/creating-new-calendars#w_on-the-network-connect-to-your-online-calendars for an example. And then you have all the bookings directly in your personal calendar app!

This almost works already with MRBS - only the authentication is getting in the way.

As suggested, an option to check for an area and/or room to allow unauthenticated read-only access in iCal format would be great.

[campbell-m]

Yes, as you say it's almost there. Is an unauthenticated GET request OK? Or would it help if you had to put a key in as a query parameter (with valid keys perhaps stored in the config file)?

[embeh]

A secret/key/token that needs to be included as query parameter would work well but an unauthenticated GET request for one or more specific rooms (and/or areas) would be good enough; it would need to come with a config option to control which ones to open up that way. We would not like the entire system to be readable via unauthenticated GET.

Thanks a lot for considering this!

[campbell-m]

Presumably if an area is marked as "open" then all rooms in that area are open. But if an area is closed, then only rooms in that area that are specifically marked as "open" are open?

An initial implementation could use the config file, but later the room and area tables could be used to store the openness (and the edit_room and edit_area pages to modify it).

At the moment the report parameters are "areamatch" and "roommatch" which match text strings for area and room names. There's no reason why those couldn't remain, but would you also want to be able to give arrays of area and room ids in the query string?

[embeh]

Presumably if an area is marked as "open" then all rooms in that area are open. But if an area is closed, then only rooms in that area that are specifically marked as "open" are open?

Sounds very reasonable to me.

An initial implementation could use the config file, but later the room and area tables could be used to store the openness (and the edit_room and edit_area pages to modify it).

config file is totally fine

At the moment the report parameters are "areamatch" and "roommatch" which match text strings for area and room names. There's no reason why those couldn't remain, but would you also want to be able to give arrays of area and room ids in the query string?

I would probably not. Instead I would rather use multiple URLs, each with a different string, for different areas/rooms. That way, I would get multiple calendars in my calendar client, with multiple colors etc.
But some others might find it useful to join multiple parts of MRBS bookings into one query.

What would be good to have is the ability to export only certain types of bookings.

[campbell-m]

I've now got a version for testing in this branch. I haven't yet implemented a key/token. The new config settings are:

// Set this to true to allow unauthenticated GET requests to report.php
$report_unauthenticated_get_enabled = false;

// If unauthenticated GET requests are allowed then only bookings in rooms
// or areas that are open will be shown.
$report_open_areas = []; // An array of integer area ids
$report_open_rooms = []; // An array of integer room ids

To use it you'll need to use report.php?phase=2&output_format=2. To restrict it to certain rooms add &roommatch=roomname and similarly for areas.

All feedback welcome.

[campbell-m]

I've now added support for keys in 9d2aae9.

[campbell-m]

What would be good to have is the ability to export only certain types of bookings.

You should be able to do this using the typematch[] parameter, eg &typematch[]=E&typematch[]=I.

[campbell-m]

Just wondering if you got a chance to test this, before I merge it back into the main branch?