[SOLVED] Permanent properties in the PropertiesService

[Andrew A.]

Is it possible for the data stored using the PropertiesService to survive a re-installation?

[Alan Wells]

My experience is that the values stored in PropertiesService are still there after a user removes and then re-installs my add-on.  Script properties are tied to the script, which is your Apps Script file, which obviously shouldn't be affected.  The document properties are tied to the document, which isn't affected by removing the add-on.  The user properties are scoped to the add-on somehow, and also don't seem to be affected.  I haven't tested the situation for myself recently.  You can easily remove the add-on, and re-install it, and see what happens.

[Andrew A.]

I privately published a test version and uninstalled it. I will reinstall it tomorrow and see if it shows the value I expect to see.

BTW which is the best to use between getUserProperties() and getScriptProperties()?

[Alan Wells]

You should always be aware of user data that should be private to them, and not seen by you.  So, don't store personal information that the user enters for settings in your script properties.  Script properties are stored in YOUR Apps Script file.  If you have lots of users, you might not want to fill up your script properties with lots of user information.  I think that the limit for Properties Service is 500kb, so you could easily hit the limit if you tried using it as a database for all your users.  The only settings that I'd put into script properties might be a couple of settings that are specific to your add-on, if needed.  You could use script properties for temporary storage, because it's easily accessible, and then transfer it out in some situations.  User properties are not shown in the File -> Project properties dialog.  So, if it's a value that you don't want the user to see, I'd user user properties.  A user could use the same add-on in multiple documents, so you wouldn't want one document using another documents settings when the add-on runs, and so if the settings are specific to that document, then I'd use document properties.  If you only want to maintain one setting for multiple documents, then I'd put it into user properties.

[Davis Jones]

For my app, I used the script properties as a  datastore for temporary information about automations. In my experience so far, it's been best to use the user properties in the add on, not the script or document properties.

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/8a436050-7165-489b-9afc-3fcaffc897cd%40googlegroups.com.

[Andrew A.]

You guys have inadvertently poured cold water on my project hehehe

I was planning on using the Properties Service to monitor my add-on "trial period"... I had even come up with a simple but efficient method.

Now I'm back to the drawing board.

To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-community+unsub...@googlegroups.com.

[Alan Wells]

I use properties service to keep track of when the trial period is over.   I store a value as milliseconds for the trial period expiration date, and never delete it.  My system also stores payment information externally in case the add-on doesn't find any stored values in Properties service.  Why wouldn't your current system work?

[Andrew A.]

I think I misunderstood your previous message because I imagined that I, if I have many users, I would be clogging my script properties. Do you mind shedding some light on how exactly you prevent this?

[Alan Wells]

My add-on allows being used in multiple documents for each user.  So I store payment information in user properties.  If the user opens a second document, and they are paid, they can still use the add-on without paying again, because the payment status is store in user properties.   Using Properties Service avoids the need to make an external request every time that the add-on needs to test the payment status.  But if something ever did go wrong with the data in properties service, and the add-on didn't find a setting, it would make an external request to check the payment data in my account.  If you wanted the user to pay for every document that the add-on was installed in, then you'd need to put some setting in document properties.

Depending upon whether you use PayPal or stripe, or whatever you use, and how you implement it, the flow of events may be different depending upon how the payment information can get back to your add-on.  The stripe system I have can communicate directly back to the add-on, through the server code, but my PayPal implementation can't.  It needs to go from PayPal, back to a WebApp, and then store payment data in my spreadsheet, and then the add-on searches the spreadsheet if there is a setting that a payment was made.

  So, I use User Properties to store local information about the payment status.  You could put something into script properties temporarily,  transfer it to user properties, and then delete it from script properties.  For example, let's say that someone contacts you, and wants an extension to their trial.  Or somehow your payment system had a problem, and you need to fix their payment date.  You decide that it's okay, but you need a way to make a setting manually.  You could manually update your database, or your spreadsheet, or you could add the user's email and new trial data end or paid until date to the script properties, and your code could check script properties for that special situation.

[Andrew A.]

Thanks for the insight. I hope I can borrow some ideas from this.

Currently I'm only using the properties service to handle the trial period >> PropertiesService.getUserProperties();

On Paypal I've created a subscription button so it should handle that portion for me nicely. All I need to do is check the subscription status periodically.