When I searched through Stack Overflow (and the internet) before asking this question, I only found information on making a dashboard of a single form's data, which isn't what I'd like.
I work a lot with Google Forms and I'd love to have a way of knowing how many people have responded to my different active Google Forms. By default, one must open the forms individually to find out.
I'd appreciate any ideas, pointers or existing ressources you know that could help me out : I'd love to avoid builing something from scratch!
I know of no such existing service which does this. You can however do this in Apps Script with the Forms Service and the Charts Service.
Valuable pages include getting all the forms responses
and creating charts
Good luck!
I am dealing with multiple forms as well, and I realised that you could maneuver to the "Responses" page. Click on the settings button and select response destination to be an existing spreadsheet, and select a sheet to input your files too. This may be easier although less flexible than coding a script out. Cheers!
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.
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've found lots of examples of coding the deprecated UIapp forms, but very few using the new FormApp class.
What I need is essentially a Grid control that has text boxes for input in place of radio buttons - a table in other words! I'm finding nothing that shows how to set up a table with positioning or a container.
Any suggestions? Preferably I'd love a link to a site that details lots of examples of coding the FormApp as I'm sure this is just the start of a new learning curve.
Thanks!!
Google's FormApp is limited to a fixed number of Item types - just those that are provided by the Forms Service GUI. There is no way to create custom question types or layouts. I suspect the limited ability to customize is the reason you don't find much effort dedicated to creating script examples.
If the data you are collecting requires a different layout than any of the provided "Items", then your only practical option within the Google Apps Script world is to create a custom interface using UiApp or the HtmlService, and record responses into a spreadsheet.
Alternatively, you can submit a feature request on the Google Apps Script Issue Tracker. However, unless the Item already exists in Google Forms (Google Docs), it's unlikely to get any traction from the Google Apps team. (My opinion - I don't speak for Google.)
I have a web app that data is submitted from a Ui embedded in a Google Site and saved in a spreadsheet. I am thinking about switching to scriptDB instead, but I am unsure about querying and displaying data dynamically. The last time I checked it was not possible to refresh a sites page from within a script, so as a work around I wrote a .html page with javascript that accesses the spreadsheet via the key and uses the Visualization DataTables to produce a quick and nicely formatted query. I would like to retain this functionality if possible. Could anyone make some possible suggestions?
Regards,
Shawn
This is doable today via UiApp (see the Charts api, and note that you can add a Chart to a UiApp).
To auto refresh:
You can use CheckBox.setValue(value, fireEvents) - but you may hit quota issues (there is an example somewhere around). If you hit quota issues, then I suspect HTML service is your best option. It also gives you better control.
Here is an open item requesting expanded Charts service integration with Gviz.
Although, there is limited integration at present, it needs to be expanded to group variables in tables to facilitate basic count and sum operations.
I suggest you “star” the issue to vote for it and to be notified of new developments.
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.