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
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.
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!
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.
Hi @FarmTech, I’d love for this to be made available on Farmier, but as this module was put together in a few free evenings, it most likely will require some tidying up to meet the coding standards and some further testing.
It also has a dependency on another Google PHP API client module which would probably require consideration by @mstenta and co.
This module would also currently require you to setup Google developer account for API credentials (which is not too difficult).