ICS event subscription
niccokunzmann opened this issue · 20 comments
I am building a calendar based on the events. I would like to subscribe to the events via an ICS link.
I think, this is not yet implemented.
How would one go about it to implement this? Which parts of the code should be touched?
Another place would be to use an external service. The API already exports enought information about the events so that an external service would suffice. If the external service is a node service, this makes is easier to integrate the code later.
Which way would you prefer?
Hey Nicco
There are a couple of PR to work on this already, the main issue being timezone: without it, the ICS will be invalid. So the main requirement before that is to be able to save the timezone of the event, and the only source we use (which isn't reliable) is the creator's one (the champion, when saving the event); and considering we were regarding the rework of event creation, I delayed the change. Another way would be to use the event's location, which means mapping the address to it's region's timezone.
I would prefer an internal service (but this haven't been really discussed), simply because it allows us to make use of it from the emails easily (without storing a reference as we can reuse the eventId) and purge the images when we wishes to.
Existing work on it :
https://github.com/Wardormeur/ics-to-s3
CoderDojo/cp-zen-platform#1258
Changes for the cp-local-development's docker-compose:
s3:
image: andrewgaul/s3proxy
entrypoint:
- sh
- -c
- "{ sleep 5 && echo -e \"PUT http://localhost:80/zenbookingqrcode HTTP/1.0\\n\\n\" | nc localhost 80; } & sh /opt/s3proxy/run-docker-container.sh"
environment:
- S3PROXY_AUTHORIZATION=none
ports:
- 8099:80
ics:
image: node:carbon
command: yarn dev
working_dir: /usr/src/app
volumes:
- ./workspace-zen/services/ics-generator:/usr/src/app:Z
If you wish to extend my PR, feel free to, or you can build your own :)
I'll be happy to help in both cases
Another way would be to use the event's location, which means mapping the address to it's region's timezone.
That would be good, I think. I as a creator could be in a different time zone or use a different browser at the same location at the moment I create the event.
However, people going to the dojo usually assume the dojo to advertise its time in the local time.
A short workaround would be what I have seen in the discourse events plugin. You pass the time zone as a parameter. Usually, a dojo does not change the time zone as it does not travel across borders, barely in the city. So, the parameter can be set in the url as the dojo is set in the url.
The scenarios I thought of so far were :
- embedded with the "new event" notification email
- available through the GUI to "add to your calendar" at the end of the booking flow (parents/mentor)
- available through the GUI "somewhere" (?) for champions as a personal reminder
Mind if I ask you "how" you would see it being used ?
The reason I'm asking that is that "if" we skip the embedded, making it as part of the GET events endpoint as a different representation is the most logical answer; but that excludes the most used of our parent communication channel (even though it can be at the end of the booking flow).
Fair feedback regarding the emails (cc @conoramurphy )
I like the idea of the whole planning thing, basically an exportable version of /dashboard/my-tickets?
My original idea was based upon static file as there is very few needs to change the file (create once and reuse), but I can see a simpler version being easier (passing down the tz on request as you said) if we export it from the GUI (as a first implementation that is, email can follow on once we have the TZ on save of the event).
The main issue I could foresee in all those scenario is the freshness of the data. Without a proper auth scheme, that means we can't subscribe to the .ics.
I guess that's an acceptable risk? Cancelled event are notified by email?
On other points: applications(/orders which are a grouping of tickets on the new booking flow) awaiting approval should.. not be exported by default or should be very clear that you're not accepted yet?
Hey @niccokunzmann
I think your solution to not generate a static file is actually better. The reason for that is ICS supports information like the attendants : that would let us to have a richer export of the event .
I started a simple version over there : CoderDojo/events-service#27. There is still work to use the tz, work with a list of events and such; but overall rather happy to we have a better solution :)
The main issue I could foresee in all those scenario is the freshness of the data.
Hm. My calendar (Thunderbird) GETs the ICS file every one hour. I think that is expected.
Without a proper auth scheme, that means we can't subscribe to the .ics.
I think, it is ok to subscribe to one dojo. I also think, we could make several issues for this: one minimal working prototype and other extensions to it.
MWP: ICS event export with time zone as parameter, manually set, for a dojo. The event contains a link to the event page.
On other points: applications(/orders which are a grouping of tickets on the new booking flow) awaiting approval should.. not be exported by default or should be very clear that you're not accepted yet?
For the minimal solution, no-one expects their attendance to the written to it. It is only for notification about dojo events in your own calendar.
So, there's an issue: the ics package doesn't support timezone apparently. (adamgibbons/ics#52)
I'll look into implementing it, at least a basic version, in the ics package but we could try without TZ and see how each provider works in term of import : does it take the user's/system TZ ? if so, that could simplify our deployment for a MVP version.
The issue will be for event near time zone change (DST a-like) and for events in the far future.
Added the PRs for the API server and the frontend
That's actually a different implementation :)
That means the date is stored as a floating time (https://www.w3.org/International/wiki/FloatingTime)
The "TZID" property parameter MUST NOT be applied to DATE
properties and DATE-TIME or TIME properties whose time values are
specified in UTC.
The use of local time in a DATE-TIME or TIME value without the
"TZID" property parameter is to be interpreted as floating time,
regardless of the existence of "VTIMEZONE" calendar components in
the iCalendar object.
What I was wrong at, though, is to assume a UTC date should need a timezone.
I'll revert that, and I think we can give it a go ?
Apart from the missing endpoint for the URL attribute (which I'm unsure how it's being used) which I haven't been able to understand the use for (both google calendar and gnome-calendar ignore it, so it might be either an .ics, or anything else?), I think it's production ready.
if @conoramurphy and (@DanielBrierton @ArayB or @nyashamaphosa) could have a look, that'd be great :)
Cheers;
W.
PRs to be reviewed are the following :
CoderDojo/cp-local-development#82
CoderDojo/cp-zen-frontend#248
CoderDojo/cp-zen-platform#1351
CoderDojo/events-service#27
Done and gone :)
@Wardormeur Thanks for the implementation. How can I test this? How you be sure this can be closed?
What is the user story behind this?
Here is one:
User Story 1
When I go to a dojo page https://zen.coderdojo.com/dojos/de/brandenburg/potsdam/potsdam-hpi,
I would like to see a calendar symbol.
When I click on this symbol,
A download link opens for an ICS file
The download link looks like https://zen.coderdojo.com/dojos/de/brandenburg/potsdam/potsdam-hpi.ics
User Story 2
When I log into zen
and I click on my user name on the top right corner
then, I click on My Events
When the page loads,
Then, I see a link "Subscribe with a Calendar" pointing to the ICS file
Hey Nicco :)
It's on the left column of the Dojo page, under "Time"
Edit cause I read too fast:
So right now, it only supports the first user story. If we see some usage, or anybody wants to work on it, the 2nd one could be done too ;)
It's on the left column of the Dojo page, under "Time"
Ohhhhh. It is not blue!! O.O Erm, I mean, I tested it as a user who erm is not so fluent in viewenig web pages ;)
Thanks for the reply!
I think, making it blue can be a user story for first-timers