jonas0b1011001
commented
8 months ago since each user would have their own deployment anyway.
From how i understand deployments (i have no experience at all), the best way would be one 'official' deployment. If i'm not mistaken you can select to run the deployed code 'as the user' which would allow to save and load all settings from the user properties service. I don't know how/if triggers will work with this. So in theory the user will only need the html ui and never ever see the code or the code editor.
Lonestarjeepin
I'm sure you will find ways to run this code more cleanly and likely some things to debug. Nonetheless, I was able to create the html front-end and json storage in this version. Each calendar gets run through the startSync individually so that all of the parameters are calendar-specific. The only variables left in code.gs are the main timer (howFrequnt) and the email variables... I gave up on trying to keep the existing array of arrays so this will have to be a clean break from the old version. One other thing of note is that this is somewhat based on my syncDelay version so all of the fromGAS entries are different than before so each calendar here can write to the same Target Calendar without conflict. I'm thinking it would be a good add to look for the old fromGAS=true and just delete all of those entries. If we don't, there will be duplicates the first time someone runs this code. Lastly, I updated the Installation Instructions for this version, but I'm not entirely sure Test Deployments is the "right" way to launch the index.html page, but it works so I just went with it. It seemed cleaner than messing with Deployments... since each user would have their own deployment anyway. This version also already includes #372 (it was a building block for this code), #392, and #217 so we can close all of those if this gets merged.