Profile cover photo
Profile photo
Thomas Mills Hinkle
90 followers
90 followers
About
Thomas's posts

I'm running into trigger limitations in an add-on I'm writing and wondering how others deal with similar problems.

My add-on manages workflows, with a spreadsheet containing the configuration data/logic for various steps of a workflow that moves through several forms. When testing by hand, I can generate all the appropriate triggers for different forms, but when I test it as an add-on, I'm not allowed to set up form triggers from the spreadsheet (I get the error "This Add-on is attempting to create a trigger on a document that it is not currently being used in.").

After re-reading the trigger docs, it looks like add-ons are limited to one trigger per type per document anyway, so my add-on could never work.

If I make this into a standalone web app, though, am I right in thinking I would then be allowed to create all the triggers I want? If so, is there anything preventing me from basically having my add-on point to a web-app to manage the triggers? Any advice on how to make this process less confusing to users? The reason I was going w/ an add-on over a web-app in the first place is that the path to installation and use is more straightforward for the enduser.

Dumb question I can't seem to solve with google -- does anyone know how to properly escape spaces in an orgUnitPath? I'm trying to add users to the right orgUnit via script and I keep getting INVALID_OU -- our OrgUnit names have spaces in them... e.g. /Middle School/Class of 2024/

Alternatively, if I could feed the orgUnit ID to Users.insert in the AdminSDK, that could work too, but that doesn't seem to be one of the params you can pass in.

So I did too much testing today and ran into the error: "Service using too much computer time for one day"

My understanding is this is a limitation per trigger. Does that mean it's per script? Per script per trigger? Per form per trigger? Just trying to figure out if there's a good way to work around it for testing triggers.

I could imagine making a new copy of the script, a new copy of the form, etc., but don't want to waste the time if it won't help.

I don't believe I'm going to actually run into this error in production given our use cases, but I was a little careless with some of the tests I ran and ended up triggering it a bunch more than I needed to.

Today I discovered this gem: google has two different IDs for each form response, and you will get different ones when you use form.getResponses() and when you use form.getResponse() -- isn't that handy?

responses = form.getResponses()
responses.forEach( function (resp) {
idNumber1 = resp.getId();
idNumber2 = form.getResponse(idNumber1).getId();
Logger.log('%s != %s',idNumber1, idNumber2);
}); // end forEach

Thanks google...

I'm running into a limitation in FormApp that I can't quite believe so I want to check: is it really impossible to update a form response via script even though you can use the script to get a URL to let an end user edit said response?

When I try the obvious thing -- grabbing the form response by ID, using withItemResponse to add items I want to add, and then calling submit(), I get a "Sorry, this response has already been submitted." error.

If you're curious about the use case, our organization uses partially filled out forms as part of an approval workflow (people put requests into supervisors which end up creating partially filled-out forms waiting for a supervisor's final "approval" -- these get emailed out one at a time, but I'm trying to create a UI to make it convenient to handle batches of FormRequests at a time).

I've been working on a generic "Workflow" tool for use in our school and I'm curious to connect with potential users and developers as I continue work.


Right now, my tool uses a google spreadsheet to hold a list of configurable actions that are associated with one or more forms. Those actions can include creating accounts, sharing groups, calendars, and folders, triggering a secondary "approval" form email, and sending email notifications.

Right now, the tool has two uses in our own school:
1. We manage our purchase approval process using this tool, which basically ties to google forms together in order to create an approval chain, and then spit the results out in a spreadsheet the business office uses to track purchases and keep a clear accountability chain. Teachers fill out a form to request a purchase, which then triggers off an email to budget owners (department heads, etc) who approve the purchase, which triggers the generation of a PO number and the notification of the appropriate people in the business office whose job it is to do purchasing or reimbursement.

2. We use the tool to manage the digital onboarding of new staff. Principals fill out a single google form once per new hire which automatically creates a new account, adds it to the appropriate google groups, and shares specified calendars and drive folders with them (principals are presented with a checklist of options which they choose based on the role of the hire).

My goal is to build a UI that tech folks and saavy administrators could use to automate processes in their school. The end-user visible UI (i.e. the part lots of people interact with) is just google forms. Right now, there is no UI -- just a script that interacts with a google spreadsheet and forms.

Please ping me if you're interested in helping develop or test this tool in its early phases. At some point, I'd also love to get some minds in on UI design and review, as folks in this group are likely my target audience.

I'm building a tool for using google forms to handle various kinds workflows. Currently, each workflow is associated w/ a spreadsheet which holds configuration information for it and is also linked with one or more google forms.

The script is triggered from the forms, then uses various bits of configuration data from the spreadsheet to complete its work.

My question/problem is this: how do I tell the script where to find its configuration data from a given form? What I'm imagining is that the same script might ultimately have triggers for various forms for various different workflows associated with it.

Post has attachment
With google's new API, I wonder what new functionality is in store for the doctopus community.

(see announcement here: http://googleforeducation.blogspot.com/2016/05/build-deeper-integrations-with-google.html)

I'm tempted to work to build something this summer that would give us doctopus-like management of documents (i.e. documents that the teacher owns throughout the process) + a google classroom experience on the other side (classroom interface + calendar integration).

If you could access classroom's assignments, you could basically doctopus-ify them by taking control of the associated google docs, but that's not allowed with the new google APIs yet.

Given what's there now, the best I could see doing is...
1. Create a tool to create the assignments as doctopus does (doctopus team could do this, though it may be easier to just rebuild the code from scratch, truth be told).
2. Make that tool create a google assignment resource with a link.
3. Use a magic link so that student's who click it land at the correct google drive object which is created and owned by you.

Perhaps too much work for not enough gain?

I guess the question is this: how valuable is the doctopus ownership model, where the teacher controls the whole lifecycle of the document? Is it worth the effort to keep it? Is there another way to keep that ownership model and integrate with classroom?

Post has attachment
So classroom finally has expanded API access -- see https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3887

The most disappointing thing about it so far is that API access is limited to be one way. I suppose what this mostly means is that it's easy to take your fancy tool and make it able to create and track assignments in classroom, but it's much harder to make a tool that improves the way classroom itself works, which is what I'm interested in doing (I'd like to be able to do simple things, like get doctopus level of customization for how assignments look within classroom).

Anyone out there already working with the new API?

I'm very frustrated that the very model of the new API basically precludes the kind of collaboration I'd like to see. Since changes are locked down per developer API key, there's no way for developers to build a suite of tools that play well together.

I'm finding that form response URLs returned by getEditResponseUrl don't seem to be working for me. The URL is valid but it brings me to a generic error page. This is my first time testing w/ the new forms and I'm wondering if it's related but haven't yet found a bug report (just submitted one).

Is anyone else using getEditResponseUrl with the new forms successfully? Anyone else seen problems?
Wait while more posts are being loaded