Currently, AFAIK, when performing google form batchUpdate using the google forms API v1, we are only able to set the shuffle property of choiceQuestions, while for textQuestions there are no options to set the response validations, like if I want to use regex match as validation.
For Example, the request body looks like this:
{
"requests": [
{
"createItem": {
"item": {
"questionItem": {
"question": {
"choiceQuestion": {
"shuffle": false
},
"textQuestion": {
"paragraph": false
/*no other parameters to set*/
}
}
}
}
}
}
]
}
Am I missing something? Or is this feature not implemented yet?
You are correct, this has not been implemented yet. For now, these are the only options that can be used with ChoiceQuestion This is kind of expected taking into consideration FORMS API was launched just last month.
So you may want to submit a Feature Request for that missing feature.
In the meantime, you can also consider tackling this using Google Apps Script and its Forms Advanced Service which includes response validation.
Related
I'm using Contentful's GraphQL API. What I want to do is to query all the events that haven't past yet.
I tried using lt, but that doesn't seem to be working. I also found out that the date is a string, so what options do I have?
eventCollection(where: {eventEndDate: {lt: "2022-10-27T00:00:00.000-06:00"}}){
items {
slug
eventEndDate
}
}
A normal query (without the where condition) gives you:
"eventCollection": {
"items": [
{
"slug": "black-friday",
"eventEndDate": "2022-11-27T12:00:00.000-07:00"
}
]
}
You should have an eventEndDate_gte filter available. On every field, there will be type dependent filter available. It's best to use GraphiQL or the GraphQL Playground to discover available filter options.
The following filter works fine for my space.
query {
tilPostCollection(where: {date_gte: "2022-09-05T00:00:00.000+02:00"}) {
items {
title
date
}
}
}
I am using MS Bot Composer combined with BotBuilder Facebook Adapter in order to post my bot following the "new" rules of Facebook Workplace - important to remember that I've already tried to use this directly on Facebook Messenge, same situation applies.
The integration and connection works fine, the problem now is to understand how to post anything apart from text.
An example below of an attempt to get the correct template
# channelData
-```{
"attachment":{
"type":"template",
"payload":{
"template_type":"button",
"text":"What do you want to do next?",
"buttons":[
{
"type":"web_url",
"url":"https://www.messenger.com",
"title":"Visit Messenger"
}
]
}
}
}```
And then, the bot's answer:
If you go the channel data route, the Facebook adapter expects you to provide a full FacebookMessage object as the channel data. That's one level up from the JSON you've provided, so it would look like this:
{
"message":{
"attachment":{
"type":"template",
"payload":{
"template_type":"button",
"text":"What do you want to do next?",
"buttons":[
{
"type":"web_url",
"url":"https://www.messenger.com",
"title":"Visit Messenger"
}
]
}
}
}
}
However, that won't work because it's missing the other properties a FacebookMessage needs, like sender. Rather than trying to populate the full Facebook message, it may be easier to just go the attachment route instead of the channel data route. You can see how to do that in the Facebook adapter sample:
private static Attachment CreateTemplateAttachment(string filePath)
{
var templateAttachmentJson = File.ReadAllText(filePath);
var templateAttachment = new Attachment()
{
ContentType = "template",
Content = JsonConvert.DeserializeObject(templateAttachmentJson),
};
return templateAttachment;
}
In Composer, you can set the activity's attachments instead of its channel data. Just set the content type to "template" and the content to the payload of the attachment you have now, using the Facebook adapter sample's resources as a guide:
# attachment
- ```
{
"contentType": "template",
"content": {
"template_type": "button",
"text": "What do you want to do next?",
"buttons": [
{
"type": "web_url",
"url": "https://www.messenger.com",
"title": "Visit Messenger"
}
]
}
}
```
You can see how the Facebook adapter treats both channel data and attachments by having a look at the FacebookHelper class.
In the relay documentation here, it says that:
Relay uses a common pattern for mutations, where there are root fields on the mutation type with a single argument, input, and where the input and output both contain a client mutation identifier used to reconcile requests and responses.
But in the example they provided, the input and output looked like this respectively:
// IntroducedShipInput
{
"input": {
"shipName": "B-Wing",
"factionId": "1"
}
}
// IntroducedShipPayload
{
"introduceShip": {
"ship": {
"id": "U2hpcDo5",
"name": "B-Wing"
},
"faction": {
"name": "Alliance to Restore the Republic"
}
}
}
So what is the client mutation identifier? And why, and how does it get used to reconcile requests and responses?
I'm still not 100% sure what exactly happened to the "client mutation identifier," but having done some research, it appears to have been a requirement in previous versions of Relay. This PR apparently removed the requirement by replacing it with some other mechanism, but it's not clear to me what that other mechanism does. I left a comment requesting more clarification around the documentation, which appears to be out of date.
At any rate, the client mutation identifier appears to have been related to some assumptions about mutation idempotency in Facebook's implementation of GraphQL.
According to this documentation [ https://cloud.google.com/tasks/docs/creating-http-target-tasks ], one should be able to create tasks with type 'http_request' and 'http_method' set to 'POST', but the behavior is not the expected once the task is always created with method 'GET'.
After having this issue while using the Python Client Library, I've decided to try the API directly and check if it was an issue with the library or with the API itself.
Using the "Try this API" from the product's documentation page [ https://cloud.google.com/tasks/docs/reference/rest/v2beta3/projects.locations.queues.tasks/create ], I've tried to create similar tasks using both http_request and app_engine_http_request types and always setting the http_method to POST.
If I set the request body like this:
{
"task": {
"appEngineHttpRequest": {
"httpMethod": "POST",
"relativeUri": "/test",
"body": "c2hhbGxvdyBub3c="
}
}
}
...the task is created and the method is POST, like expected. But, if I set the request body to:
{
"task": {
"httpRequest": {
"httpMethod": "POST",
"url": "https://httpstat.us/404",
"body": "c2hhbGxvdyBub3c="
}
}
}
...the task is created, but with method GET instead of POST.
Here's what I get at my queue:
I believe this is a bug, and that's why I'm reporting it here with tag google-apis-explorer as recommended at the support page.
Anyway, if anyone could tell me if I'm doing something wrong or if there's any workaround in the meanwhile I would really appreciate.
Thanks!
Thank You for this post, this is a bug in the existing Cloud Tasks UI and we are in the process of fixing this bug.
In the meantime the correct HTTP method of the task can be determined by running the following command:
gcloud beta tasks describe
https://cloud.google.com/sdk/gcloud/reference/beta/tasks/describe
The above command will show the correct HTTP method for the task.
I try to use insert activity request through this special form http://joxi.net/J2bykQQS4XYxXm
{
"object": {
"originalContent": "LaLALaLALa"
},
"access": {
"items": [
{
"type": "domain"
}
],
"domainRestricted": true
}
}
but always I have 403 error in answer. http://joxi.net/DrllG33c4vnb5r
I tried to use user_id instead me but had same results :(
Most likely, you are not doing this as part of a Google Domain. Now also known as "gsuite", this allows companies to be able to post messages that are visible to other members of the same company. This does not allow you to post messages that are available for most Google+ users to see.
There is no public API available from Google to let you post to the public Google+. There is an API available to select partners (such as HootSuite) which let them post to the public Google+, but they seem to be slow or reluctant to add additional partners.