SyncDelay #372
SyncDelay #372
Conversation
SyncDelay processes each source Calendar individually instead of grouping them together by Target Calendar before processing. By handling each calendar individually, I was able to denote a Sync Delay on a per-calendar basis. The default is whatever the script trigger (howFrequent) is set too, but the Sync Delay can be set to skip syncing on a given run if the Sync Delay hasn't "expired".
|
I'd really like to avoid adding additional properties to the calendars arrays until they're redesigned (see #311). However, if this is critically needed for some reason, feel free to say so and we can discuss it further |
|
I wouldn't say the feature itself is critical (defining multiple sync schedules) although it was requested in #346 which gave me a use-case to implement this change. My main impetus in redesigning the script this way was to enable a lot of other feature-requests I've seen that (to me) would need to be executed at the individual source-calendar-level rather than the target-calendar-level. The Sync Delay feature is just a Trojan Horse for the real change in how the code executes. I agree that defining more and more parameters on the individual source calendars could be messy in the current configuration of the script and totally agree with your direction in #311. I was just hoping this might open some doors to accomplish other feature requests... and I got stuck on the idea so I couldn't stop until I figured it out!!! |
By using |
|
I've used that when I have two (or more) different scripts writing to the
same target calendar, but given that this would be the same script writing
to the target calendar multiple times I think that would still cause
conflicts. I didn't test it though. Example: SourceCalA reads from
TargetA 0 events (let's assume this is the first run ever, but the same
logic would apply to subsequent runs). SourceCalA contains 30 events so 30
get written to TargetA. Then SourceCalB wants to write to TargetA also (in
the same script as SourceCalA). SourceCalB would then read 30 events from
TargetA as being from getScriptId() and think they are events it should
understand. So then those 30 would get deleted (because they aren't
contained in SourceCalB) and SourceCalB would then write x new events to
TargetA. So each SourceCalx would always conflict with any other
SourceCaly every time the script is run and only the last one in the loop
would exist in Targetx.
Keep in mind the main change I made to this version is to have each
SourceCal run individually instead of collapsing them together to run
against a given Target (I completely removed condenseCalendarMap). The
variable "triggers/delays" was just one feature this change enabled. My
hope is this change will enable other source-calendar-specific features to
be deployed in the future (handling 5xx errors, only syncing specific days
per source calendar, etc.). Even some of the current global variables
(onlyFutureEvents, addEventsToCalendar, etc.) could be individualized per
source calendar. I know Derek doesn't want to over-parametize (if that's a
word) and I totally get that so I'm not trying to open Pandora's box. But
if #311 can be figured out, this could be the foundation it could be built
upon to enable more fine-grain control of source calendars.
FWIW, we could use sourceURL as the fromGAS. We don't need a separate
parameter. It just needs to be unique for each SourceCal. I just thought
the friendly name would be easier for troubleshooting when reading the
logs, etc. and I think I even saw a feature request where someone was
asking for that SourceCal name to be appended to the event title or
something like that so it could serve multiple uses.
…On Tue, Oct 10, 2023 at 4:26 AM jonas0b1011001 ***@***.***> wrote:
For the developers: I had to modify the fromGAS entries (5 in total) to
use the sourceCalendarName instead of "true" to avoid conflicts with
multiple sources writing to the same target calendar
By using fromGAS=${ScriptApp.getScriptId()} we would allow users to set
up multiple independant copies (with different sync intervals) of the
script working on the same target calendar.
—
Reply to this email directly, view it on GitHub
<#372 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AM7OH5PBKWL64NMNAMT36H3X6UIDBAVCNFSM6AAAAAA5L2UFW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJUHAYDKNZWGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I totally get that. |
|
Gotcha. I wasn't planning on this, but if I take a stab at #311, what do
you see as the features that need to be captured to enable that? I'm
seeing something like a list of source calendars that the user can choose
from (or option to add new/delete). Then once they select a source
calendar from the list, it would bring up a details page for that source
calendar where all of the relevant parameters could be set either through
checkboxes, dropdowns, input fields, etc. depending on the parameter. Are
you seeing anything different or something I've missed?
KW
…On Wed, Oct 11, 2023 at 10:15 AM jonas0b1011001 ***@***.***> wrote:
I totally get that.
My suggestion was more like a possible easy to do workaround for different
sync intervals..until we get #311
<#311> and
possibly a quite substantial code overhaul done.
—
Reply to this email directly, view it on GitHub
<#372 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AM7OH5MYJD3J3KCUSFQDHDDX62ZZTANCNFSM6AAAAAA5L2UFWY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
#311 is about replacing the sourceCalendars array with a js object. Creating a html UI is not neccessarily needed for that, however i don't want to stop you from giving it a go ;P |
|
That makes sense, but Derek made a comment in there about some efforts in
the past to develop an HTML UI too. Do y'all have any of those old
attempts you could share? I've never done any of this in Google Script,
but I'm guessing the HTML could read/write to the JSON so people could use
either one??
…On Wed, Oct 11, 2023 at 11:37 AM jonas0b1011001 ***@***.***> wrote:
#311 <#311> is
about replacing the sourceCalendars array with a js object. Creating a html
UI is not neccessarily needed for that, however i don't want to stop you
from giving it a go ;P
—
Reply to this email directly, view it on GitHub
<#372 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AM7OH5IMPMR22F7ZGGFAQQLX63DK3ANCNFSM6AAAAAA5L2UFWY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
There is one in this repo |
Updating this PR to include changes made in v5.8 of master.
Updating PR for changes made in v5.8 release.
SyncDelay processes each source Calendar individually instead of grouping them together by Target Calendar before processing. By handling each calendar individually, I was able to define a SyncDelay on a per-calendar basis. The default is whatever the script trigger (howFrequent) is set to, but the SyncDelay can be set to skip syncing on a given run if the SyncDelay hasn't "expired". For example: if howFrequent is 15, but SyncDelay on a given calendar is 60, then that calendar will only sync once every 4th iteration of the script (aka once per hour). However, another calendar in the same script could still sync every 15 minutes.
For the developers: I had to modify the fromGAS entries (5 in total) to use the sourceCalendarName instead of "true" to avoid conflicts with multiple sources writing to the same target calendar (but not at the same time). However, the first time you run this new code, that change itself will cause duplication of all events that currently existed because they were from fromGAS=true. I didn't include it here, but a possible solution would be to put in a step that checks for fromGAS=true and removes all of those events.