We have a Gmail Contextual Gadget, it is published in Google Apps Marketplace.
For OAuth1.0 to 2.0 migration, as recommended in https://developers.google.com/apps-marketplace/v1migratev2 we created a new version of our Gmail Contextual Gadget, published it in Google Apps Marketplace, and associated it with the old version.
Now, to the question: the old version of the gadget was installed in about 50 domains. What happens to them after September, 30? Do they migrate automatically? Or what do we need to do so that our users could continue using our gadget?
UPD:
As soitof pointed out, Step 4 of the migration guide suggests that we call 'PUT https://www.googleapis.com/appsmarket/v2/upgradableApp/listingID/cwsID/domain'
Yet, I am unsure about how to proceed from here. Namely, what the migration strategy should be.
The first thing is that we don't keep the list of domains where our gadget is installed,
we only have the number of domains. I suppose we could track the requests and build that list.
Here comes the second point: do we fire that PUT requests manually? It is not difficult for our 50 domains, but what if there were, say, 10000? My wild guess would be that we make the old version of our app fire that PUT request automatically, but I am not sure if that's a good idea.
I would welcome some advice, 'best practices', 'guidelines' etc. on how it is usually done.
No they will not migrate automatically, you have to migrate them. Its a simple task you just need a bit of info about your old and new app.
All the info is found here:
https://developers.google.com/apps-marketplace/v1migratev2
UPDATE:
So to migrate you will need two versions of your gadget published, one in the old market place and one in the new one.
So right now you have your old GamV1 gadget listed, you'll need to submit your new one for publishing. Once it is approved, and listed, you can begin the migration. You have to wait till it's published since you need information from its public listing.
You'll need to build a list of domains and perform the PUT on each one manually. I made a script that performed the PUT on a domain name, then made a wrapper script that fed it domains one by one.
Related
I am developing a Google Action for Google Assistant and it is not yet a state where I can release. Even so I want it to be available for some tester, and in a near future, my client.
The simulator with the "test" is somewhat limited at auth request, name recognition (since it will only knows my action) and experience (to show my client), so I prefer not to depend on it for this case.
I found it is only possible to interact with a test version of an action if the project owner's account is logged in as a Google account in the phone where you want to call the action. Is it correct? Or there is another way?
I even tried adding my wife's Google account as a viewer to the project, but I am unable to call my action from her phone.
You can add people as a viewer to the project. Before those users can call your action on any of their devices, they will need to use the test console at https://console.actions.google.com/ once, this will enable testing on their device. After that they will be able to interact with your action on their devices.
Do note, the time in which the action is available on their account is limited by a time period (about a couple of months). If they cant access the action any more after a couple of months, just repeat the above step to reactivate testing for their account.
Update
One thing that you could consider in the two approached posted by #Prisoner and me is if your testers need to test on just a device or need access to the console as well. Using the approach from #Prisoner will allow your users to test on devices. The above approach will also allow testers to use the console at https://console.actions.google.com/.
In addition to #Jordi's answer, you can also do an Alpha Release of your Action. This lets you permit up to 20 additional accounts to the released version
Once you permit them using the console, you will send them the opt-in URL, which they should visit on a mobile device with that account. Once they have opted into the Alpha, they can activate it using the regular trigger phrase.
We have website/portal currently successfully running live. There was a module called Lets say "A". Which is already developed.
Client asked to add some more tremendous amount of features and updates to that module.
Now we need to give beta release of this new development to specific group of users and rest of the users will have same old application.
Can anyone suggest a better and a kind of good standard approach to give beta releases on Live Site.
Thanks
This comment mentions a partial roll out in Chrome Web Store. Where can I find that feature? My extension has more than 8,000 users but I don't see any partial roll out feature and I'm afraid to send the next version to all users at the same time.
I don't think it's documented anywhere. And I was wrong!
Documentation link: Control how fast your app reaches users.
In CWS lingo this is called "Controlled Rollout".
If you don’t see the max deploy percentage control, it may be because of the following:
You have less than 10,000 users. Currently the “controlled rollout” feature is only available for items with at least 10,000 users.
You need to upload a newer (higher) version of a package to use the “controlled rollout” feature. We can’t apply a controlled rollout to an already published package, because it may have already reached 100% of users.
It should show on the Edit page after you upload a new version that's not published yet. Here's a mention of it and how it should look:
Also, I've never actually tried using it.
Update: In the new Webstore Dashboard it's called "Partial Rollout" and has the same 10k users requirement.
I am working on a little project that I would allow me to update the location of a food truck that moves often.
I know there are apps that one could download but I'm hoping to avoid telling people to download ANOTHER app to keep up, instead it would be awesome to just have it searchable on google maps and have GPS directions to the truck available.
I see that the places API allows adding and deleting of places, I'm not sure how long that takes to update but I will figure that out once I can actually add a place.
Has anyone been able to succesfully do anything like this before with node? I understand that the javascript API will not do add requests so it seems node is the best solution here.
If you look at the places API, Google said:
When you add a place, the new place is available immediately in Nearby Searches initiated by your application. The new place also enters a moderation queue to be considered for Google Maps.
So your truck won't be visible on the Google Maps until after Google Maps decided to add it. But more than this, if you look at the deleting section:
A place can only be deleted if:
*The place was added by the application that is requesting the
deletion.
*The place add request has not successfully passed through
the Google Maps moderation process, and the place is therefore visible
only to the application that added it.
Which is, in other words, you would not able to update its position ever again after they approved your location.
In stead, you should use the Javascript API to make your own webapp, to get something like this http://planefinder.net/flight/CPA872
UPDATE
Unfortunately, Place Add has been deprecated on June 30, 2017 and will stop working on June 30, 2018. So you cannot use this method anymore. For further details please refer to the corresponding geo blog post.
I'm trying to develop a site, where users will be registered directly on it, as opposed to being authenticated by Google mail etc. Beside the usual username/password I need to collect more data from the user - name, address, etc. What would be the quickest way for adding the desired functionality? Short of writing my own Auth plugin I see two options:
Create my own registration form (which I kinda need to do anyway) and use HashDB for storing the passwords and later authentication. However, yesod.auth.hashdb seems to be gone from the latest version (why?) and is only available separately here: https://github.com/ollieh/yesod-auth-bcrypt/ . Is something wrong with it? Security flaws?
Use http://hackage.haskell.org/package/yesod-auth-account - looks much closer to what I need, because it already provides registration page, but it doesn't seem to be supported by the latest yesod 1.2.5 and it is not clear how to integrate my additional fields into the existing registration process