Prefix metadata in ExtendedProperties of GCal events #38
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
No longer consider events with an empty SourceID field in their metadata as invalid. This case could only be triggered if a Google calendar event contains `ExtendedProperties` in which the `SourceID` is set to an empty string. However, this can not be the case for events synced with somewhat recent CalendarSync versions.
The `ExtendedProperties` of an event are potentially shared with other tools. Thus, prevent conflicts by prefixing our metadata.
alxndr13
approved these changes
Aug 1, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR removes the (not really necessary) special case to clean up events with an emtpy (but existing) SourceID field in their ExtendedProperties, as suggested in #33.
The more important change is the introduction of a prefix for the metadata fields to prevent potential collisions. To ensure backwards compatibility, the code falls back to the old unprefixed keys if the prefixed keys do not exist. The idea here is to eventually drop support for the unprefixed keys, but support both to simplify the transition.