Greetings FarmOS community!
Just wondering if there has been any talk in having the farmOS calendar be exportable to a format that can be importable into Google Calendar?
This would be a useful feature as we use the cloud calendar to operate our farm along with farmOS. Tracking Activities, Tasks etc.
Thanks in advance for any feedback!
Shan
I’m glad you asked about this @FarmTech ! I actually looked into the feasibility of this for farmOS 2.x a couple weeks ago. I’ve been meaning to share what I found so I might use this issue to do so 
Basically there are two options: the iCal calendar format, and the CalDav calendar/server protocol. iCal is the simpler of the two & can save calendar events to a .ics file, while CalDav (a subset of WebDav) has many more features (like username/pass authentication) but requires that a server is running in order to retrieve data.
TLDR; I think iCal is likely the best (and simplest) bet for farmOS! If I have time I’m hoping to implement this in a custom module before Spring because I’d love to sync my garden tasks to my calendar 
farmOS iCal:
I found the Drupal views_ical module and tested it with the development version of farmOS 2.x (looking again I see that there is a version of this module for Dupal 7, too). The configuration was pretty cumbersome (poorly documented & lots of “gotchas”), but eventually I got it to work!
I was able to create “Views” of farmOS logs in an iCal Feeds format. Visiting the link allows you to download a calendar.ics file and import into you calendar app, OR use the same link as a “Calendar subscription” in most calendar apps. I tested both of these options with local calendars apps on my computer (macOS Calendar and Thunderbird). I couldn’t test the subscription with Google Calendar since my farmOS serer wasn’t running on a public domain (just on my computer), but the import worked, so I’m confident the subscription would work too!
Each event can have a link to the log, include notes, flags, etc. There’s really a lot that is possible. I just found that the Views setup was quite complicated. I think this could be simplified by creating a feeds/export system that is dedicated to farmOS Logs.
The major complication/limitation with the calendar subscription option is data privacy (this has been mentioned before, perhaps on this forum or elsewhere). This requires that the farmOS server have a publicly accessible URL that the calendar app can subscribe too. As a result, this means that a subset of the farmOS logs + log metadata would become publicly accessible. A couple options around this are using randomly generated URLs OR require private keys to access well-known calendar URLs. Such URLs might looks like: /calendars/{secret_id} or /calendars/logs/harvests?secret={secret_id}. Changing the secret values would require a change in all subscribed calendar apps.
BUT the ability to manually download an .ics file & manually import into your calendar app wouldn’t have this concern! Files could be generated & downloaded when you are logged into farmOS, no URL would have to be public. It would just become a chore to do this on a regular basis, that’s what nice about the subscription 
farmOS CalDav:
Like I said above, CalDav can have more features (not only events, but also tasks + contacts) and can also require username + password Authentication since it runs on a server. This is basically what’s used to add a Gmail calendar to your phone or computer calendar app.
I looked into this option some too - since farmOS is running on a server, it should be possible as well. The sabre/dav library is probably the best bet here. I was actually able to create a module that provided a sabre/dav server within farmOS. The library is actually pretty great; it’s designed for applications that want to provide a WebDav server connected to their specific data model - exactly the missing link for providing farmOS Logs as Calendar events!
Getting this to work is fairly tricky… this laravel-sabre repo was a good reference. It does something similar to what we would need, essentially instantiating the calendar server on EACH request, provide “events” (logs) to the server, build a response, and go back to sleep… it’s possible, but maybe not ideal. I also see it being more difficult to create calendars that only display certain types of logs.
What would really make WebDav worthwhile is the Authentication. Because sabre/dav allows custom Authentication Backends I think it might be possible to connect the farmOS/Drupal Authentication to the caldav server but I didn’t get far enough to test this out. It also raises a bunch of other questions like permissions (who has access to calendars), changing passwords, etc…
So that said…
I think iCal is probably the easiest calendar format to add to farmOS. But I wasn’t satisfied with views_ical. Since farmOS really only needs to export Logs as events (is there anything else??) I don’t think we need the Views integration, it’s just too robust. Creating iCal feeds of Logs would be pretty simple by itself. I’d love to see a dedicated UI where users could create “Calendars” and specify which logs are included. Some ideas:
I think that is all possible!! Each “Calendar” could have it’s own URL and/or secret key.
*paul121 ends brain dump
The calendar integration would definitely be nice. One idea I had reading @paul121 brain dump is would it be possible hooking to the Google tasks api? Then you could manage log tasks from Google, should you choose and you could still see them on your calendar. I don’t know all the logistics is syncing status back and forth though.
Oh that’s interesting @applecreekacres ! I’m not familiar with the Google tasks API, but I imagine you configure farmOS to push new logs to Google, or write a script that pulls new logs from farmOS and sends them to Google.
Something I didn’t mention above is that it would be quite complicated to allow creating farmOS logs from a separate calendar app. This wouldn’t be possible with iCal, but could be possible with CalDav. The CalDav API just doesn’t have a way to specify a log type, log notes, assets, users, etc… without doing something very custom. The calendar app would likely need to support these things as well. And that point…you’re just reinventing the farmOS Log API - I suppose this is what we want to be careful of
This is a fantastic brain dump!
Thanks for laying this out @paul121. This helps understanding big time. This all makes sense as it seems there this could be a valuable feature in a few ways. even simply being able to export and import.
To have it real time with a subscription is ideal though for sure. It makes sense to start simple. And to have a way to create custom logs from farmOS for the calendars would be a slick way to define specific farmOS -> google calendars that can be used to track farm tasks without having to be logged in to farmOS.
Even to use the farmOS harvest calendars to track seed -> harvest metrics knowing when food is available for market. Making these calendars able to be subscribed to for instances like openfoodnetwork.net. We could connect our food harvest calendars to it. just ideas
Oh interesting… Kinda like a public calendar that customers could subscribe to? So a “Garlic harvest” log could basically be used to advertise this? …dang, that would be cool! Logs could be flagged with a special flag for this.
I think it’s fairly easy to embed a Calendar subscription in other sites too. So it really wouldn’t be too hard for a farm to add these calendars to an existing “marketing” site
YES! Awesome. Exactly… have them tagged. Like harvest logs of all specific types, seasonal etc.
Oh yea and embed. Great idea!
yea i can see the crop plan module being great in this application
Great thoughts @paul121 @FarmTech @applecreekacres !
I closed Feature Request: Calendar & task integration · Issue #171 · farmOS/farmOS · GitHub (related issue) and linked it back to this topic.
Related: we need to decide what to do in farmOS 2.x in general with regard to the calendar.
In 1.x we used the Calendar module: https://www.drupal.org/project/calendar/
There is an alpha release available for Drupal 8/9 - but to be honest I was never really satisfied with the Calendar in farmOS 1.x. It felt too much like we were trying to reinvent the wheel, when most people already have a calendar application they use. So maybe instead of incorporating a Calendar into farmOS 2.x we should just consider exploring the iCal options described above.
What do you all think? Is it worth having a Calendar UI in farmOS? Keeping in mind that it will never be as feature-rich as dedicated calendar apps, and will be something we need to continue to maintain moving forward.
I don’t really use the in-built calendar, but an external calendar would be good - would it be able to modify events in terms of the dates/time/titles? Or just for viewing only?
It sounds like the iCal approach would be read-only.
+1 for integrating with existing calendars. I think that’s the best way to go.
My 2 cents, from another post. I vote for keeping a native calendar within farmOS! 
The great thing about modules is: we can do both!
Here is the module that we used in farmOS v1: Calendar | Drupal.org
It is currently in “alpha” for Drupal 9. The first step would be to drop it into a local development environment and test it out.
My suggestion would be to create a separate add-on farm_calendar module that can be maintained outside of the farmOS codebase. This gives users the option to download and install the module on their instance, allows for more experimentation, and can eventually be “merged” into farmOS core itself as it matures and if there is community interest in doing so.
My preference would be to keep the module dependencies of farmOS core “beta” or higher. So hopefully the Drupal Calendar module would also make progress at the same time!
Good points, @texasecofarms.
I wonder if there’s a way to get the best of both worlds. For folks who want more robust calendar features, we could provide some functionality to export to iCal or Google Calendar, since those are relatively simple data formats as far as I understand. And at the same time we could put more effort into farm-specfic UI for the calendar. I also wonder whether plans (eg, crop plans, grazing plans, etc) could be an alternative to the traditional calendar view, if some folks prefer.
I’ve been playing with the Google Calendar API a good bit over the last couple of weeks and using it to pass log updates to a calendar as events. It all works fairly well but I think I’ve come across a limitation of the developer account. It seems that refresh tokens for published apps last for 6 months and can be renewed, but refresh tokens for apps in test mode only last 7 days and don’t renew. Which means needing to use a Google Web Login Screen once a week.
To take an app out of test mode requires going down the Google verification process route which I believe could be costly and lengthy, unless the app is marked as internal use only but that requires a subscription to Google Workspace. I’m avoiding this option for the moment because I already have a Microsoft 365 subscription which provides me with similar services with arguably better productivity tools and more cloud storage.
Has anyone any alternative options?
The options I’m currently considering are:
Change to Google Workspace from Microsoft 365.
Change to using the Microsoft Outlook API. (but I think this is likely to run into additional costs too with Azure)
Use TimeTree as an alternative Calendar TimeTree API Document - TimeTree Developer Platform.
Run an opensource Calendar Service on my own hardware
@paul121 did you get any further with your calendar with CalDav?
Never mind, it would seem I can publish without verification, just get a bigger warning about unverified app at login. I’ll test this over the next week or so and make sure the token dose not expire.
I haven’t gotten further but I’m quite interested in it. I don’t think it’s quite possible to run a full CalDav server in solely a Drupal module… which means running CalDav needs additional hosting configuration/dependencies and becomes much harder.
What I’m more interested in is building iCal feeds from logs. This would let you “add a url” or “subscribe to a calendar” in external clients themselves. I believe there’s actually a Drupal module that lets you build iCal feeds using Views - which is so cool! Last I tried it there were some gotchas and didn’t fully work when configuring an iCal view of Logs. Also using Views means that users would need Views UI to configure this themselves which is quite a large barrier.
Instead of views I think we could build something similar but simplified and more custom for only logs and iCal feeds. The idea here is that you might want scheduled harvest logs and input logs to include different information (fields & content in various formats) in the calendar event. You could even build two different feeds of harvest logs each with different information, depending on who would be consuming the events. Although I worry that such flexibility would grow into recreating views again 
but maybe we could use the existing views structure, just with a simplified UI for only building iCal log feeds.
Not sure if that makes sense but that’s what I’ve had in mind 
I was thinking too that it would require running a separate service, something I should avoid due to the limited resources of the Raspberry Pi’s running my farm, I think if I start going too far down that route I’d be better off paying for a VPS.
That makes sense alright.
At the moment I’ve nothing ready to use but have enough worked out to create google calendar entries when logs are created/updated (assuming my refresh tokens last longer than a week now). I was thinking of just adding in an “add to calendar” check box to all log types, then have a calendar entry pushed out to a calendar via the Google API for any log saved with that check box selected. I’d not planed for any calendar view within farmOS but I presume a Google calendar could be added in as an iFrame.
But I think that your iCal approach sounds much more flexible, so I may explore that a little too.
Made a start today at a module to create events in Google Calendar from logs
It is fairly similar to my notifications module but I’m leaving it separate for now due to the complexity of the Google API, thankfully though someone has already done a lot of the hard work.