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.
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 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?
edit:
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.
Iāve used some of @SirSundays iframe code to embed a google calendar along with my calendar events module, so now log creation events can be sent to a calendar and easily viewed from within farmOS.
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).
but maybe we could use the existing views structure, just with a simplified UI for only building iCal log feeds.
