Google Calendar Query node - returning deleted events.

[ukmoose]

By design it would appear that Google's Calendar API returns deleted items (why? It appears a crazy choice to me!).
This means the Query node which returns the next entry can return a deleted event.

Whilst the status can be seen within the raw data object, given some of the data is exposed within the payload object should the "status" of the event be included?

Or should the node be able to return the first non-deleted event?

[hindessm]

I think it should probably ignore deleted events - at least by default. I'll take a look at fixing this.

[hindessm]

How are you getting deleted events returned? During testing, I deleted events (via the web ui) and they didn't seem to get returned.

[ukmoose]

I created an event using the google calendar web ui.
This gives returns data.status "confirmed". If I then double click on the event in the google calendar web ui and select "delete" and then rerun my node-red query it still returns the same event but with data.status as "cancelled".

[hindessm]

I can't reproduce this, deleted entries aren't returned for me, but from your description I can write the code for a fix. Can you test the fix in commit 351d93e?

[ukmoose]

yes it works, but I've also found another way!
add showDeleted: false into the request.qs = array.

Still doesn't explain why for me they are getting returned by default but it does fix the problem ;-)

On looking at that commit would it be better to have the time check being greater than or equal to, rather than greater than? If the next event is starting now, should it be returned rather than skipped? But thats not related to this issue so I'm happy to close this whichever solution you go for.

Many thanks for your speedy work!

Mark

[hindessm]

I've submitted a pull request for the fix - generally I'd keep the issue open until it is merged - but since it only affects you and I'm sure it will get merged fairly quickly it doesn't matter.

I used "greater than" intentionally since the comparison is with milliseconds so it will be exceedingly unlikely to occur and writing it like this makes it clearer not to expect it. If/when I change it such that the time is configurable in a node/msg then I'll change it to greater than or equal.