I'm creating Teams app, but I have already created bot application and resources needed, thus I don`t need form Teams toolkit to create additional ones. Is it possible to use already build ones and where should I state them in Toolkit files(manifests/parameter files)?
According to MS documentation upon Provisioning and based what is selected to be used in Teams app - Provisioning command triggers to create the resources(https://learn.microsoft.com/en-us/microsoftteams/platform/toolkit/provision), and to repeat my question, is it possible to use already build resources and not to create new ones?
Any suggestions/ideas/experiences?
By exploring config file I have found in https://github.com/OfficeDev/TeamsFx/blob/main/docs/fx-core/teamsfx-env-config.md that if I provide the resources they will not be previsioned and created in azure and I have set them: , but still on Output Provision in the cloud I get:
Thanks for your question, if you have already your own Azure Bot service and hosted bot application code. The only thing you need to do to connect your bot with Teams is to update the bot definition part in Teams manifest file.
Related
I'm created a connected app in salesforce and consume contacts in my application, but for this, a need a consumer key from connected app.
I would like to create an application that consumes my customers' contacts without them having to create a connected app and generate a consumer key, in order to access their list
I saw this in a hubspot integration in salesforce, where it was possible to install a hubspot package and consume the contacts, I tried to create something on the appExchange but I was unsuccessful.
Can anyone tell me a tutorial for this? I've been searching for days and I can't find anything.
without them having to create a connected app and generate a consumer
key
Good. They don't have to. Have you actually tried connecting with 1 org's client id/secret to another org? Have you hit any issues?
Think about it. You're making a new awesome mobile app that connects to Salesforce. You'll want to make it work just like that, on any phone, any SF org, without org admins having to do any installation steps. You can generate OAuth2 keys in any org, even your personal Developer Edition. You could generate them in sandbox - but they'll be deleted when you refresh it.
Check if my answer https://stackoverflow.com/a/69810951/313628 helps you understand the whole thing.
Now, there might be some things you do want in every org, maybe some config custom table... You'd have your mobile app and then maybe a Salesforce plugin published on AppExchange. But that's battle for another day and you don't need it for basic functionality.
I have an App Registration, which is currently within my DEV environment. It contains a lot of settings (Mainly App Roles). I tried to download the Manifest.json and upload it again to the new registration, but the setting were not written at all.
Is there a better way than recreating the whole App Registration from scratch for the TEST and PROD environment?
Move comment to answer so that this post can be treated as answered.
Using script to generate registrations in all environments could be one option.
The important thing needs to remember is handling the GUID such as OAuth2Permissions id, appRoles id and so on.
Known issue:
Installing google-cloud-sdk (linux package or from tarball) has a quirk where you cannot create projects from the command line before accepting the terms of service.
Steps to reproduce:
Download sdk, untar, move folder to home directory and add google sdk root directory to PATH using install.sh
Initialize and login with: $ google init
Create a project from the CL: $ gcloud projects create --set-as-default
This will spit out an error like:
ERROR: (gcloud.projects.create) Operation [cp.5641973328385684887] failed: 9: Callers must accept Terms of Service
I hazard a guess that accepting the terms of service have not been built into the command line initialization yet. Omitting such a fundamental step to an installation process should be illegal, with consequences ranging from death by a thousand key-stokes, to 'build an operating system in headfuck'... but that's just me...
We find the solution in the most unholiest of places: the google cloud control interface (cloud console).
Go to your cloud console
Create a project by selecting 'select a project' (top-left next to "Google Cloud Platform" and then 'create project' (top-right in the popup window).
This will prompt the terms of service agreement and you may carry on after agreeing to the terms of service.
I hope this helps whoever else stumbles upon this most infuriating of errors.
Live long and prosper
Bitshift
Let's not be so dramatic with "death by a thousand key-strokes". This is a security measure that should be implemented. Security is not always convenient but can save your checking/credit account a lot of grief.
Imagine this theoretical scenario. You provide me with a service account that has the roles to create a project. I create a new project. This project is created under your Google Billing Account. I know what I am doing with Google IAM so I remove you from the new project and make myself the Project Owner. Now you have no access to the new project but your credit card is paying the bills for my project. I think you would then be screaming "death by a million key-strokes".
There are two types of projects:
Independent projects not part of an organization.
Projects that are part of an organization.
If you are part of a Google Cloud Organization, you can easily create projects up to your quota limit (default is 5). No prompting, accepting TOS, etc. Using the CLI to create a new project is effortless.
If you are not part of an Google Cloud Organization then you are basically creating a new account, you need to set up account billing, accept terms of service, etc. This means that you should not use the CLI to create a new project as the CLI does not prompt you for the items that a new project requires. Why, the CLI should be using a service account. The service account is not the IAM member that owns the account. This forces you to log into the Google Cloud Console using your User Credentials to create the new project.
For anyone getting this message when trying to create a dialogflow agent:
Go to https://console.cloud.google.com, login and accept the displayed terms and conditions.
Afterwards it worked for me...
I am hosting some Web Applications in Google Cloud Platform using App Engine and those are for internal purpose only. One month ago I got a mail from Google Cloud Team, saying one of my apps needs verification. By based on their response I did some research and finally migrated all apps to the Organisation level as they mentioned in documentation (below link for reference). https://support.google.com/googleapi/answer/7394288#gsuite-app
But, yesterday also I got another notification regarding the same.
May I ignore this notification, or are there any further steps I need to complete?
As stated in this other documentation page:
If you're creating an internal web app for which [...] your project is
associated with a Cloud Organization that your users belong to, you
don't need to go through verification. Internal users of your
application won't see the unverified app screen.
If your application will only be used by internal users belonging to the same organization as where your project is located, you can ignore this message. It was probably triggered by the fact that your application is indeed not verified (although you do not need to do so).
So if that is the case, you will only need, as stated in the link you shared, to create an Organization and then migrate your existing project to that organization (then make sure that the users who will be accessing the app belong to the same organization).
I believe there is an undocumented Google API available to create and manage Google Cloud Console (and App Engine) projects on behalf of third party users.
Does anyone know how to use it?
I think older versions of the Google Eclipse Plugin obtained an OAuth2 token in the (undocumented) scope https://www.googleapis.com/auth/appengine.admin, and this allowed it to generate a Cloud Console project on your behalf. The latest version doesn't seem to do this. App Engine's own appcfg.py also uses this scope, but doesn't seem to do much more than deploy the code - I'm looking to change core settings for the project, such as Name, Redirect URLs, and Web Origins.
Any information would be appreciated.
I maintain a WordPress plugin providing secure Google Apps Login for end users, and currently have to give detailed instructions to admins for creating a new Cloud Console project manually, and entering settings such as Redirect URL. Ideally, I would create a simple on-line service to do all of this for them.
Thank you!
It is possible to programmatically create a new Developer Console project on behalf of a Google Account (yes, you read that right). You do so in a very roundabout way:
Request the https://www.googleapis.com/auth/drive.scripts scope from the user (standard OAuth 2.0 flow).
Use the Drive API's drive.insert method to create a new file with a mimetype of application/vnd.google-apps.script.
Somehow try to get the project ID, maybe by uploading some Apps Script code? This is the part that I was never able to figure out.
A little known fact is that every Google Apps Script project has a hidden Developer Console project associated with it. This project is not shown in the list of projects, but it does exist. It is created automatically when the user starts a new Apps Script project, and the drive.insert method is enough to cause this to happen.
How do you get to the hidden project? Well, the only way I know of is to open the Apps Script project from the Drive website, open the "Resources > Advanced Google Services" dialog, and click the link to the Developer Console. You'll find the project ID in the URL.
Aside from not being shown in your list of projects and not being able to use App Engine, this is a normal Developer Console project. You can add additional OAuth client credentials, service accounts, Compute Engine instances, etc. And of course once you have a project ID, all of the various management APIs will work: creating new virtual machines, making use of a service account's impersonation ability, etc.