I'm trying to work out the best way to display a Google Spreadsheet in the members section of a website.
Although the info in the spreadsheet isn't hugely sensitive, I'm not keen on publishing it and embedding it using an iFrame, so am trying to find a way to embed the spreadsheet while still keeping it private.
I've tried using the Spreadsheets API (via the PHP Zend library) with some success, but it seems to fall apart if a lot of the cells are empty. As I'd also ideally like to keep any cell styling, does anyone know of a way to embed the spreadsheet via an iFrame or similar without publishing it?
Any PHP/Javascript solutions most welcome!
Well if it's a member's area - you can use the GDATA AUTH method (part of the php Zend Library) to ensure authentication - even if it is private (you don't need to publicly publish your spreadsheet) - I'm sure you already know this.
If you just want to pull the data - the documents list query and then by use of tables and add CSS to it to retain styling can help.
google: google spreadsheet api IBM - and there's a tutorial that shows a few examples. Hope that helps.
Related
I am looking to find out if it is POSSIBLE to restrict EDITORS from downloading, copying or printing a Google sheet or other documents in a Google Drive. We share sheets/documents with our customers so they can fill in the details. For that we need to make them EDITORS (so they can edit and even invite others to the party). I know that we can restrict COMMENTERS and VIEWERS from downloading, but in our case we need to prevent EDITORS.
We have a LOT of intellectual property in our sheets (custom formulas and approaches), and we would like to be able to prevent people from simply downloading it. As I understand it this SHOULD be possible using the Google Drive API, but I have not been able to figure out how to do it, yet. Looking at the API it obliquely says it MAY be possible, but it is not clear :-(
Direction, or sample code, would be VERY much appreciated.
TIA
It's not possible to restrict editors from downloading files. The documentation mentions that only commenters and viewers can be prevented from this. Then in the API docs concerning permissions and their definitions you will see that there's nothing controlling downloads either. This is just a UI change.
If you think about it, the reason is clear: Even if you manage to stop direct downloads, to anyone with at least read access to the file or API this is just a minor inconvenience. They can still read all the content and metadata from the API and replicate the file perfectly. Even viewers with copy disabled can still read the formulas from the formula bar. Sharing the Sheets file is inherently unsafe if you have confidential data in it, since a determined attacker can still get all your trade secrets easily. You're only supposed to share these files with trusted users.
My suggestion is to take a different approach. Do not share the Sheets file at all and use something else as intermediary to request data from your customers. For example:
Create a Google Form to save the responses to a Sheet. Your customers will only need to fill out the form and the sheet will be filled with data that you can handle on your side.
If you need the users to also view some information in the Sheet before filling out their info you can build an Apps Script Web App that displays only the plain data that you need to show them. With this you can hide the formulas and other sensitive information. Using templates and server functions you can allow the users to interface with the Sheet data similarly to how they do it now, but with a more restricted view. You could even allow them to edit only the data you want them to. This requires more work and is starting to delve into web development, but It's much easier than a fully fledged website since the hosting and interfacing with APIs is handled by Apps Script.
You could just create your own application and use the Sheets API to read and write data from the Sheet. This is pretty much the previous suggestion but much harder, though in the end it will give you more flexibility.
The bottom line is that sharing your Sheet in any way is akin to giving your users full database read or write access, and there's no single setting that can prevent that. Your best bet is to avoid sharing these files and use a different method to request user data.
My current site (Golf League) uses several scripts to allow players to schedule whether they are playing, display various results pages etc. It seems as though the New Google Sites implementation does not allow a parameter to be passed in the page url and get picked up by an embedded Google Web App (published from my script)
This link shows an example https://sites.google.com/site/kitchenergaffers/home/general-gaffers-information/publish/directory-of-results?display=directory
There is my webapp (built from a GAS) that does a doGet(e). The "display" parameter tells this script which page to format and display which it gets by extracting the e.queryString. I use a similar approach for players scheduling their absences. Another url parameter identifies the player who may be changing their availability.
It seems as though this ability is not going to be supported in the New Google Sites, so I am looking for an alternative (and free) web building facility where I can launch GAS web apps and access the page url parameters the same (or similar) way. Wordpress, Wix etc may be candidates, but it is difficult to tell from their introductory info whether it can be done. If someone has already found a site facility and methodology I would appreciate the guidance.
Just in case anyone finds this in a search, I have found a workaround.
What I had missed is that a script can be the target of a URL and will execute in a browser on its own. It does not need a "hosting" page. So to achieve what I need to do, instead of sending the link with the Google sites page, I can send a link with the script directly and it will happily execute in its own browser environment. In some cases, I may need to add a bit of text to the html returned by the script to replace that which was on the Sites page
So this link (below) achieves what I needed. Be aware that the links displayed by the script, are currently still to the original sites page.
https://script.google.com/macros/s/AKfycbxichdoGrHbImuudkJbuhhD00GpHvVvc-Ph_BTpSI4863pMevVx/exec?display=directory
I used this code to insert documents directly into a Google spreadsheet without having to upload files and then create hyperlinks. However, as google moved to the new spreadsheet...
Warning: The UI service was deprecated on December 11, 2014. To create user interfaces, use the HTML service instead.
So know I need help fixing lines like; var app = UiApp.getActiveApplication();
If someone could clarify the different types of programming direction you could take this project from, that would also be very helpful, I am not really sure if I need to work with Javascript or HTML now.
The answer to your question will depend in large part on how you are using UIApp. In most cases it's not as simple as changing a few lines of code but more of a script redesign.
If you are using it to create a custom user interface, your path forward would be to rebuild your interface as HTML/Javascript and serve it to the user with HTMLService. The service is overall much more powerful/flexible and provides a better end-user experience but it means rewriting how your script works. If you want to take a look at a helpful example on how the HTML Service works take a look at the HTML Service Guide or this quick-start example of an add on.
You can still link this html interface with your script using the google.script.run service but you will need to redesign your code/application to work with the new input methods. The good news is although UI service will sunset on June 30, 2015, "Service will no longer appear in autocomplete, although existing scripts should still function."
It's worth considering alternate ways to accomplish the same goal. The best way to do that is to start by asking "What is the intended use of this script? What problem does it solve?" There may be a better way to accomplish that task which may not even involve updating the script.
This is not related to the new spreadsheet version, the message you get is because UiApp has recently been deprecated.
A Google search would have shown you a few tracks to find your way.
One of the best I found is this one from Sandy Good : Google apps script UI services to HTML services
It shows a typical example of conversion to HTMLService.
I really like the look of jsPDF but I can't seem to find any documentation for server side usage. The page here seems to suggest that this is possible, but the link for an example is broken or no longer exists. I would really like to use this library in a Google Apps Script project if possible.
The new home for jsPDF is here. Note that the "Server-side will work anywhere" promise is no longer presented. Chances are that it would work on Node.js, for example, but since Apps-Script is an incomplete javascript implementation it might not work there.
You can generate PDF files from within Apps-Script already. If the subject document is in Google Drive, then you can use getAs("application/pdf") to request the document as a PDF. (If it's not a Google Drive document, then first turn it into one.) Read over 4 ways to do Mail Merge using Google Apps Script, method 3, for an example.
I would like to (programmatically) convert a text file with questions to a Google form. I want to specify the questions and the questiontypes and their options. Example: the questiontype scale should go from 1 to 7 and should have the label 'not important' for 1 and 'very important' for 7.
I was looking into the Google Spreadsheet API but did not see a solution.
(The Google form API at http://code.lancepollard.com/introducing-the-google-form-api is not an answer to this question)
Google released API for this: https://developers.google.com/apps-script/reference/forms/
This service allows scripts to create, access, and modify Google Forms.
Until Google satisfies this feature request (star the feature on Google's site if you want to vote for it), you could try a non-API approach.
iMacros allows you to record, modify and play back macros that control your web browser. My experiments with Google Drive showed that the basic version (without DirectScreen technology) doesn't record macros properly. I tried it with both the plugin for IE (basic and advanced click mode) and Chrome (the latter has limited iMacro support). FYI, I was able to get iMacros IE plug-in to create questions on mentimeter.com, but the macro recorder gets some input fields wrong (which requires hacking of the macro, double-checking the ATTR= of the TAG commands with the 'Inspect element' feature of Chrome, for example).
Assuming that you can get the TAG commands to produce clicks in the right places in Google Drive, the approach is that you basically write (ideally record) a macro, going through the steps you need to create the form as you would using a browser. Then the macro can be edited (you can use variables in iMacros, get the question/questiontype data from a CSV or user-input dialogs, etc.). Looping in iMacros is crude, however. There's no EOF for a CSV (you basically have to know how many lines are in the file and hard-code the loop in your macro).
There's a way to integrate iMacro calls with VB, etc., but I'm not sure if it's possible with the free versions. There's another angle where you generate code (Javascript) from a macro, and then modify it from there.
Of course, all of these things are more fragile than an API approach long-term. Google could change its presentation layer and it will break your macros.
Seems like Apps Script now has a REST API and SDK's for it. Through Apps Script you can generate Google Forms. This API was really hard to find by trying to google for it and I haven't yet tested it myself, but I am going to build something with it today (hopefully). So far everything looks good.
EDIT: Seems like the REST API I am using works very well for fully automated usage.
In March(2022) google released REST API for google form. API allows basic crud operation & also added support for registering watches on the form to notify whenever either form is updated or a new response is received.
As of now (March 2016), Google Forms APIs allow us to create forms and store them in Google Drive. However, Forms APIs do not allow one programmatically modify the form (such as modify content, add or delete questions, pre-filled data, etc). In other words, the form is static. In order to serve custom, external APIs are needed.